Introduce semantic parsing in Line Impact calculation

This is already done to some extent, but here are a few ways in which interpreting code semantically could improve the approximation of dev cognitive effort. This list showcases examples of when making a specific change to the code *requires* another follow-up change. Usually, the follow-up change is complementary, but does not act in any way to evolve the codebase (not more than the initial change did).

Examples:
1. Adding another potential type to an object (should get all Line Impact) vs adding an "else" branch in the section of the code verifying that type
2. Acquiring a synchronization-type object vs releasing it
3. More generally, any resources that need symmetric operations, such as allocating memory in C
4. Extending the db schema of an object to house another column (vs adding that new property to trivial API/method calls on other layers of the app)
5. Creating a new type of Error object/event vs "catching" it in all invocations of the error-triggering code