Transport: "combolining" proposal

combo-lining proposal. An evolved actions proposal with link-setting that gives relational data priority while allowing a clean way for extensions like transactional data

* Assertion: Relational is the common case and transactional is the exception and therefore transactional needs to be optional
* When using OSDI relationally, attributes and other data should be in the easy and obvious places, behavior should be intuitive as if transactional did not exist.
* Transactional should be defined in such a way that it could have been written as an OSDI extension specification


* Create representations have inlined resources like person.  This avoids composite update complexity
* when reading resources a standard HAL response representation is used where associated resources are linked and optionally _embedded
* when updating a resource with PUT or PATCH, only the attributes of the targeted resource are included.  Updating an associated resource must be done directly on that resource.


* Assertion: Transactional data is known/created by the server not the client.  The Create representation just contains 1 person information.  If the server supports transactional data, then it will create the donation_transaction resource.
* Transactional data is cleanly layered in if the implementation supports it.  It is a separate resource that can be linked to and embedded in a donation resource retrieval. 
 * The embedding of donation_transaction allows the client to get both pieces of data in the same request if it wishes to.
* While this proposal prioritizes Relational data, when transactional is implemented and in use, it's person shows up as an embedded peer to the relational person.


* Assertion: Criticality of changing associations is fairly rare.  Most of the time you can just delete a resource and recreate it.  However there are some exceptions where it is needed.  We should have a pattern for this that is narrow in scope to minimize server complexity.
* Changing an association (say reassigning an event to a different organizer) is achieved by link relations like "osdi:set_organizer" on an individual event resource