[feature]: allow pipeline configurations to access the already configured `pipelineConfig` variable

[steven-terrana]

Feature Description

to minimize duplication in the Pipeline Configuration, allow resolution of the pipelineConfig variable within the configuration.

Open Questions:

1. should the value of pipelineConfig be the current configuration file or the current aggregated pipeline configuration

[cokieffebah]

currently, technically, it would have to be the aggregated because if you override an existing field that is not allowed to be overridden the local value is not valid

root tier pipeline_config.groovy:

libraries {
  @merge mylib { var = false } // not allowing overridding
  @override mylib2 { var2 = false } // not allowing merge
}

final resolved pipeline_config.groovy

libraries {
  mylib { 
    var = true 
    var2 = pipelineConfig.libraries.mylib.var // technically 'false' but you might expect 'true'
    var3 = pipelineConfig.libraries.mylib2.var // ??
  }
  mylib2 {
    var = true // wont be set because @merge was not used in ancestor config
  }  

}

[cokieffebah]

the above makes me think we should only allow the 'local' config, because it is simpler and call it something like localConfig to distinguish it from the 'aggregated configuration' that pipelineConfig normally represents