Adding latest and release fields to MavenMetadata, using them in AddDependency

[greg-at-moderne]

What's changed?

Two things:

1. Adding new fields to MavenMetadata "record" - latest and release

<metadata modelVersion="1.1.0">
  <groupId>commons-io</groupId>
  <artifactId>commons-io</artifactId>
  <versioning>
    <latest>2.18.0</latest>   <---------------
    <release>2.18.0</release> <---------------
    <versions>
      <version>2.17.0</version>
      <version>2.18.0</version>
    </versions>
    <lastUpdated>20241119205217</lastUpdated>
  </versioning>
</metadata>

2. Using them in AddDependency recipe, so that it honors input set to latest.release as taking the value from the top-level release field.

What's your motivation?

Address feedback from one of the OpenRewrite users.

Anything in particular you'd like reviewers to focus on?

Yes!

1. Does the way MavenMetadata changes are handled provide compatibility?
2. The change in the version resolution logic is local to this single recipe (AddDependency) as I read this is the intent in the project. All recipes seem to have their own version matching logic.

[timtebeek]

Would it not make more sense to add these at the end of the argument list, such that we can switch back to (implied) AllArgsConstructor later?

[timtebeek]

Do we need this test class at all? Seems to be covered by MavenMetadataTest already, and then I'd rather not maintain the constructor call here if we can avoid it.

[jevanlingen]

I tend to agree, (small) integration tests over unit tests (unless the unit has very nasty code you really need to test to be sure it works correctly).

[timtebeek]

Perhaps good to already deprecate this one, to nudge folks to move over.

Suggested change

	public Versioning(
	@Deprecated
	public Versioning(

[jevanlingen]

To be honest, I don't like this architectural change (I also discussed this with @Laurens-W). I think it is better for both component isolation and your mental model to keep helper methods in its own class. So in this case the findVersionToUse should stay in the InsertDependencyInOrder visitor.