Report hardcoded and dynamic dependencies versions

[LouisCAD]

To help users migrate to versions defined in versions.properties from hardcoded versions in gradle scripts or buildSrc, we should, by default, report separately these, and hardcoded version ranges, allowing to disable these two reports separately.

These reports would simply appear in versions.properties as comments, with commented version properties to use in the case of hardcoded versions. The report header would include instructions to replace hardcoded versions with the version placeholder.

In the case of version ranges, there would be a warning as to why it's dangerous to use version ranges, and instructions too.

Further improvement could automatically find fully hardcoded versions in build.gradle(.kts) files and replace them with the version placeholder, and suggest using "Replace in Path" IDE feature (cmd/ctrl + shift + F) with file and string literal filter otherwise.

A possibility is also to search and replace automatically in buildSrc files named like dependencies, libs, libraries or versions, and and offer to replace it all by version placeholders and versions.properties values.

[LouisCAD]

After some dogfooding, here's what I found out:

Reporting hardcoded versions on the fly (when version placeholder replacement is performed) is not good, because it makes warnings recurrent, even though they might be irrelevant if you need to have a specific old version for a module in your project (e.g. an Android 4+ and plain JVM mixed project that would need to use two different OkHttp versions).

Also, having tons of warnings is not a good user/developer experience either as it can feel overwhelming, especially for onboarding users that did not ask to find all the issues.

So, I have a plan:

1. Make versions placeholders replacement silent, this need to just work
2. Report counts of hardcoded and dynamic versions when refreshVersions is run as follows:
3. Count the versions that are hardcoded
4. Count the dynamic dependencies that have no preferred versions by analyzing the version constraints
5. For each of these 2 counts, generate a warning for each of them being above zero
6. For the hardcoded simple versions, suggest:
   1. to run a (yet to be named) task that will display the available updates for hardcoded versions
   2. to run the (yet to be named) migration task that will attempt automatic replacement off fully hardcoded dependencies, and list all the remaining ones in a comprehensive manner (per-configuration of each project).
7. For the dynamic versions with no preferred versions, warn (in red) that it can lead to unreproducible builds, unwanted opt-in to unstable versions (dev, alpha, etc) that it is dangerous and link to relevant Gradle doc, suggesting to replace with version placeholder (maybe also have a task try to do it automatically?)
8. For the dynamic versions with preferred versions, warn that there's no first class support yet, and suggest to create an issue if needed, linking to issue creation page