[TransWarp] Proposing API changes to peak.binding, et al

[Phillip J. Eby]

I've begun the process of refactoring the binding framework to better 
support things like adaptation and "suggesting" parent components, as well 
as removing redundant interfaces, introspection, etc.

As part of this process, I'd like to streamline all binding constructs to 
use keyword arguments to describe any "standard" attributes of a 
binding.  For example, attribute name, documentation, interface to adapt 
to, and "activateUponAssembly" should all become keyword arguments, that 
are the same for every kind of binding.  Many of these bindings now accept 
positional arguments for some or many of these items; I'd like to remove 
this support.

While doing this, I'd like to change the 'provides' keyword argument 
spelling.  The term "provides" is now fairly well established as referring 
to what protocols/interfaces an object provides.  But the 'provides' 
keyword doesn't declare what the attribute provides, it declares what 
configuration key(s) its component wants to publish it under, for the 
component and its subcomponents to use.  Also, for historical reasons, the 
current mechanisms supporting this check to see if 'provides' is a tuple, 
and if so, iterate over it.

I'd like to change the name to something that better describes its 
function, like 'publishForKeys', 'supplyAsKeys', or something like 
that.  I'd also like to required that the value always be a sequence, so 
that introspection is unnecessary.  (The original "nested tuple" support 
was for compatibility with __implements__, but it turned out in practice 
that we never really wanted to publish a component as a utility for 
whatever interfaces it might implment.)  I'm open to suggestions as to a 
better name, but would like to get this settled today if possible.

I'd also like to find out if anybody is actually using the 'useSlot' 
capability of peak.model StructuralFeatures.  I'm beginning to think that 
this is actually a YAGNI, and I see a way to clean up some related things 
if I can get rid of it, at least for a while.  Ultimately, I'd like 
StructuralFeatures to have more in common with peak.binding attributes, 
possibly including the ability to cache a computed value, and I'd like to 
get rid of some of the duplicated/overlapped infrastructure between the two.

And speaking of getting rid of things, I'm considering ditching 
'bindToParent', 'bindToSelf' and 'bindToUtilities'.  The former two are 
redundant, in that 'bindTo("..")' and 'bindTo(".")' do the same 
things.  TSBO-APOO-WTDI (There's should be one -- and preferably only one 
-- obvious way to do it.)  'bindToUtilities()' was used for only one thing 
in PEAK and was later ditched.  And even the thing it was originally 
created for is likely to go away...

That thing is objectFactories and stateFactories for naming contexts.  If 
we use adaptation instead of utilities for serializing/deserializing 
objects, these are no longer needed.