WIP: Jenkins: Allow inheritance when defining build specs

[dnakamura]

This greatly reduces duplication in the build specs

[dnakamura]

This is still a WIP since I still have to do a bit of cleanup and and documentation work to do. However here are some brief notes a bout the changes:

• Instead of living at the top level of default.yml they now reside underneath the buildspecs element
• I've added a BuildSpec class to the groovy config to calculate the buildspec specific variables
• The BuildSpec class differentiates between scalar and vector values, and behavior changes depending if you call .GetScalarField() or .GetVectorField(). For scalars, override inherited values. Vectors are appended to inherited values
• You can specify SDK version specific values on any variable
• Specifying version specific values is also optional (if you don't give one, the same value is used regardless of SDK version)
• You can also specify 'all' in the same way you would specify a version specific variable. This behaves as if it were an inherited value (so it gets appended to all vector variables, and for scalars, acts as a default unless you specify a version specific value)

[dnakamura]

@AdamBrousseau

[AdamBrousseau]

Jenkins test sanity win

[AdamBrousseau]

jenkins compile win

[AdamBrousseau]

jenkins compile win jdk9

[AdamBrousseau]

jenkins test extended xlinux

[AdamBrousseau]

jenkins test extended xlinux jdk9

[AdamBrousseau]

Jenkins test sanity win jdk10

[AdamBrousseau]

Jenkins test sanity win,xlinux jdk10

[vsebe]

YAML has a feature called anchors. The anchors can be used to avoid duplication (no need for another class):
Set an anchor:

linux_x86-64_common: &linux_x86-64_common
  boot_jdk: ...
  release: ...

linux_x86-64, linux_x86-64_cmprssptrs extend linux_x86-64_common:

linux_x86-64_cmprssptrs: 
  <<: *linux_x86-64_common
  extra_configure_options: ...

linux_x86-64:
  <<: *linux_x86-64_common
  extra_configure_options: ...

[vsebe]

@dnakamura please have a look at YAML anchors

[dnakamura]

The problem with YAML anchors is that the "extension" semantics only support map types. This is fine for most of our needs but it falls flat when it comes to extra_configure_options. This is important for Large heap and/or cmake builds. Ideally it should be trivial to add a large heap build saying that it is identical to an existing configuration, but you just add --with-noncompressedrefs option to configure.

[AdamBrousseau]

FYI #2118

[AdamBrousseau]

@dnakamura can you rebase this and restart any conversations needed to get this merged