enable deltalink, deltadeletelink in delta resource set

The only time we should receive a link/deletedLink in a request is a PATCH against a collection, which might look something like this:

PATCH http://host/service/$metadata#Customers

{
    {
      "@context":"#Customers/$deletedLink",
      "source":"Customers('ALFKI')",
      "relationship":"Orders",
      "target":"Orders(10643)"
    },
    {
      "@context":"#Customers/$link",
      "source":"Customers('BOTTM')",
      "relationship":"Orders",
      "target":"Orders(10645)"
    }
}

The above request deletes a link from customer('alfki') to orders(10643) and adds a link from customers('bottm') to orders(10645).

This is using the old syntax for links/deletedLinks. The newer, preferred syntax to represent the same request would look like:

PATCH http://host/service/$metadata#Customers

{
    {
      "@id":"Customers('ALFKI')",
      "Orders@delta" :
      [
        "@removed": {
          "reason":"changed"
        },
        "@id":"Orders(10643)"
      ]
    },
    {
      "@id":"Customers('BOTTM')",
      "Orders@delta" :
      [
        "@id":"Orders(10645)"
      ]
    }
}

This second request updates customer('alfki') by adding removing orders(10643) and updates customer('bottm') by adding orders(10645). i.e., it's equivalent (but more general than) the first (legacy) scenario.

We should have a common way of representing both the above requests to the WebAPI developer. I don't want the WebAPI developer to have different code to deal with the legacy syntax versus the new syntax – in the object model, the legacy scenario should be handled by the general object model.

Start by tracing how the delta resource set represents legacy links and deletedLinks versus the newer @delta representation. Identify the object-model boundary exposed to WebAPI developers and determine how both request forms can produce the same link updates. Done means the legacy scenario is handled through the general object model without separate developer-facing code.