Introduce consistent pattern for dealing with cross-project globals

[mark-vieira]

We have a number of "global" properties that are created from various places and shared across the project. We do this in various ways, mainly via setting extra properties on the root project, and/or subprojects and then reading the same way.

There are a number of issues with this approach:

1. In general it involves a shit load of dynamic dispatch which is slow. If I set an extra property on the root project of "foo" and then ask for project.foo in a sub project Gradle and Groovy have to do a ton of lookups before we finally find this thing. We should go for an approach that's a bit more explicit so don't have to traverse the whole project property tree to find this thing.

2. There's no type safety here. If we change the types of these things it's a pain to refactor.

3. It's not clear at all where these things come from.

4. Since these things are all mutable it's very easy for build scripts or plugins to clobber these properties. We should strive for immutability by default and make mutating explicit.

5. There's little consistency in how we share this stuff. Sometimes they are extra properties, sometimes extension objects. Sometimes we add only to the root project, othertimes we add to subprojects as well. We need to settle on a pattern.

6. Due to recent refactorings, some of these items are not available until execution time so configuration time usage needs to be deferred. Right now this just manifests as "property 'foo' doesn't exist". We should enforce execution time reads such that devs get a better error message "property 'foo' is not available at configuration time".

[elasticmachine]

Pinging @elastic/es-core-infra

[mark-vieira]

@atorok @rjernst please add any of your own concerns to this issue.