Extend heuristics for version replacement

[lukaszwawrzyk]

Each dependency kind should have configurable list of applied huristics in specific order. Usually they should be applied from most strict and specific to most general.
In the first stage, the list of heuristics for each dependency kind should be put in code, later it can be exposed through the yaml config.
Each heuristic should have some name.
Heuristic is applied on set of files defined by an orthogonal feature: #61 - for now the paths to look are hardcoded.

I will outline ideas for heuristics. As a part of this tasks it should be translated to a set of actual heuristics and ordered in an optimal way.

Each time when we look for version to replace, we know exact name (in case of maven group and artifact) and version of the library that is currently used. This makes the search much easier.

General ways of declaring a dependency

1. Version only
   This would be the least specific heuristic. Just look for exactly the same version string in given files and replace it. Probably the heuristic should fail if such version is found twice.

2. Match gradle style strings
   In case of maven dependencies, match strings like "group:artifact:version". Extra variation would be to handle "group::scala_artifact:version" scala artifacts with double colon (it is not supported natively, but someone could use such syntax and process it in code, as it is popular).
   More loose variant of this heuristic is to look for any string literal that contains group, artifact and version (not necesarly split by colon).

3. Match python method calls
   Dependency can be created as maven.artifact(group, artifact, version) or using a custom method like _scala_dep(group, artifact, version).
   It would be best to have a simple parser of method call syntax (or advanced regex) in order to extract tokens used as arguments, either standard or kwargs. Then the heuristic could look for group/artifact/version among these args. Keep in mind that method calls may spread over multiple lines.

Additional changes applicable for general heuristics

1. Look just for artifact and version (group may be added in a loop for example). It is a more loose variant. Note that it would be the default behavior in python/js/go world as they use just one component for naming a dependency.

2. Scala deps handling: omit _<scala_version> suffix from the artifact name in all heuristics during lookup as it might be abstracted out in someones code.

3. Handle variables
   Sometimes near the group/artifact, you may find an identifier of a variable instead of the actual version string as the version is factored out to a variable. In that case, version of the variable should be extracted and heuristic should look for assignment expression VAR_NAME = "version" and replace it.
   the variable can be used as argument to a function call, but also in case of strings as "group:artifact" + VERSION_VAR or "group:artifact:%s" % VERSION_VAR