Parameter wiring refactor

[aaronwalker]

Add support for outer component parameter wiring to allow for simpler components with no external component dependencies.

Support automatic output parameter wiring based output parameter discover removing the need to explicitly define a component parameter as an output parameter.

Also we should be able override this behaviour with something like

  Component template: 'ecs', name: 'myecscluster' do
    parameter name: 'SecurityGroupBastion' value: 'bation2.SGRandomName'
  end

[toshke]

We should remove StackParam and allow ComponentParam to take isGlobal as method parameter. Additional behaviour implemented in ComponentParam should be bubbling parameter to top of the CloudFormation stack if no values are provided explicitly in outer component.

[toshke]

Wiring output parameters automatically by name, and allowing for them to be passed directly from parent component should remove the need of OutputParam statement.

[toshke]

@aaronwalker @Guslington

Suggestion for providing mapping and output parameter values below, let me know what you think

# mapping values defined with cfmap(mapping, map, key)
Component template: 'ecs', name: 'myecscluster' do
    parameter name: 'Az0' value: cfmap('AWS::AccountId','AWS::Region','Az0')
end

# two syntaxes for OutputValues cfout(component, output) or <component>.<output>
Component template: 'ecs', name: 'myecscluster' do
    parameter name: 'AllowedSG' value: 'subcomponent.BastionSg' 
end

Component template: 'ecs', name: 'myecscluster' do
    parameter name: 'AllowedSG' value: cfout('subcomponent', 'BastionSg')
end

[toshke]

WIP in progress on https://github.com/toshke/cfhighlander/commits/params_refactor

This actually is not compatible with current templates due changes in OutputParam behaviour, we just may want to leave 'old behaviour' for time being.

[toshke]

@aaronwalker @Guslington @jaredbrook looking for your input on below

With full cloudformation template model now available, we could dynamically add outputs to subcomponents. This would make easier for person consuming the cfhighlander template to pass one of it's resources as parameter to another one.

See below for example

Component template: 'loadbalander', name: 'lb'

Component 'ecs-service' do 
      # There is output for load balancer on loadbalancer template, so it can be consumed directly
      parameter name: 'lb', value: cfout('lb.loadbalancer')

      # Target group is not defined on template as output, but exists as resource
      # this would add output dynamically 
      parameter name: 'lbtargetgroup', value: cfref('lb/TargetGroup')
end

[toshke]

this has been implemented last year