Implement "joining" together of multiple parameters

[rjplevin]

Separated out from #656.

Implement the @defcomposite option to join parameters in sub-components to a single name in a super-component. Proposed handling:

Joining parameters is permitted if:

• the sub-component params are not otherwise connected
• the sub-component params have no default values, or all have the same default value

Once parameters are thus joined, it should not be permitted to set any of the individual sub-comp params directly, nor to connect any of them individually. That is, you can't do:

@defcomposite foo
    Component(x)
    Component(y)
    Component(z)
    joined_param = Parameter(x.p1, y.p1, z.p2)
    connect(y.p1, z.var1) # NOT ALLOWED
end

This also suggests means disallowing set_param!(composite, ...) to be called on parameters referenced by joined parameters. If we only allow set_param!(m, ...) this is fine, but we need to remove deprecated methods, e.g., that operate on component paths or component path strings like "/foo/bar".

Note: A version of the following appears as comments appear in types/defs.jl, lines 116:141.

Rather than store a Vector of ParameterDefReference, I think instances of this class should store multiple references, all of which share one (local) name and at most one default
value. The refactored classes might look like this:

# This provides a common point (AbstractDatumReference) for referring to both 
# param and var references.
@class DatumReference <: NamedObj

struct UnnamedReference
   root::AbstractComponentDef
   comp_path::ComponentPath
end

@class ParameterDefReference <: DatumReference begin
   # N.B. name::Symbol is inherited from NamedObj
   default::Any    # allows defaults set in composites
   refs::Vector{UnnammedReference} # one or more parameter references
end

@class VariableDefReference  <: DatumReference begin
   # N.B. name::Symbol is inherited from NamedObj
   unnamed_ref::UnnamedReference  # a single variable reference
end

The main job is reviewing, and, where needed, revising any code that touches these classes. The other important piece is reviewing cases of parameter setting or connecting to ensure none of the restrictions above are violated.

[corakingdon]

notes from 3/19:

• I'll implement this as described by Rich above
• possibly rename second two types to match how they are viewed from the outside, something like "CompositeParameterDef". These are actually definitions of parameters and variables in the composites.
• CompositeParameterDef and LeafParameterDef etc. would inherit DatumDef, all should have optional keyword arguments for defaults, units, and descriptions. One can override at the composite level. (if they are different at the leaf level and aren't overridden, then error)