Improve gradle dependency resolution/handling

What problem are you trying to solve?

Up until the introduction of lockfiles we could "decently" resolve dependencies for gradle projects using the Maven classes. During the introduction of lockfiles we had some improvements of the transitive dependency gradle project marker but this only showed the gaps for gradle using the maven resolution even more.

Together with @shanman190 we decided to create this ticket to at least log the impact of not doing a gradle specific dependency resolution. I quote the legend himself:

We have made it a LONG way by only using the Maven-worldview. Given lockfiles are a Gradle specific feature, we have now kinda opened that door and have inadvertently raised this long known, but hidden behind the closed door of Gradle specific dependency resolution. Now that is the very question that I think we(larger collective) probably need to answer or write a ticket for.

At the moment, there are a few gaps that make gradle specific stuff hard like:

• Complete dependency information
  • Project (ie. Other projects of a multi module build)
  • Ivy
  • File/FileTree
  • Attributes
    • Platforms
    • Variants
    • Constrainted? Plugin managed? ...
• Customized projects such as user specified paths, customized buildscript file name, ...
• Dependency locking
• gradle intra-project relationships (eg. a dependency on another module in same project)
• ...

(FEEL FREE TO EDIT TICKET DESCRIPTION TO ADD/EDIT!)

Describe the solution you'd like

Nothing just yet. But we need to identify, discuss, divide in subtickets and take up...