Composite constructors

We discovered in #183 that it's really convenient to be able to construct Composites using the object that you're wrapping, as opposed to the things that constitute it. For example

a = (x=5.0, y=4.0)
da = (x=3.0, y=2.0)
Composite{typeof(a)}(da) # convenient when you've already got the object
Composite{typeof(a)}(; da...) # less convenient when you've already got the object (current implementation)

This is particularly acute for objects such as Dicts that can contain quite a large number of fields, so splatting them and reconstituting them would involve a non-negligible amount of compute.

Other than the aesthetic appeal, I can't see a good reason to prefer our current interface over the one introduced for Dicts in #183 .

Obviously, changing this would be breaking and a bit annoying, so we want to try and get it right.

Review the current Composite constructors and compare them with the Dict interface introduced in #183. Work out the breaking-constructor behavior and validate that wrapping an existing object is supported without requiring splatting or reconstitution; the issue does not name specific files or tests.