Add support for build-level conventions for Property objects

[ghale]

This adds support for build-level conventions for Property objects exposed by software type model objects. For each software type registered, a corresponding convention object is registered as an extension on the Settings object. These can be configured in the declarative settings script. Then, when the software type is referenced in a project (and the corresponding plugin applied) the convention properties from the settings object are wired as the conventions of the properties on the project model object.

This also introduces a @NestedRestricted to specify nested objects in software types that should be visited while navigating the properties of the object.

Note that we will support additional types (such as Dependencies objects) in follow up work.

Reviewing cheatsheet

Before merging the PR, comments starting with

• ❌ ❓must be fixed
• 🤔 💅 should be fixed
• 💭 may be fixed
• 🎉 celebrate happy things

[ghale]

@bot-gradle test this

[bot-gradle]

I've triggered the following builds for you. Click here to see all build failures.

• PullRequestFeedback build

[ghale]

@bot-gradle test this

[bot-gradle]

I've triggered the following builds for you. Click here to see all build failures.

• PullRequestFeedback build

[h0tk3y]

I wonder if it would be clearer if the software types would be exposed not in the immediate scope of Settings but in a nested scope with a clearer name like conventions {...}. But that's not something we should finalize right now, anyway.

[ghale]

I don't feel strongly about this either way. I had originally thought I would add a top-level conventions {} block, but then decided it wasn't adding any value beyond simply nesting the configuration and thought it might be simpler for users if the convention blocks were at the top-level just like they are in the project scripts. I could easily be convinced to move it into a nested block, though. I'd be interested if anyone else has any strong opinions about this...