Resolve sort_by specification issue

[mmccool]

Resolves #480

• Proposes change that allows field to sort_by to be specified by either a top-level field name or a JSON pointer (with RFC citation)
• an implementation could support both, since JSON pointers will always have a leading slash in this context, so if there is no slash, it can be interpreted as a field name... unless a field name starts with a slash. Don't do that.
• Should cover all existing implementations so testing data should still be valid
• We should clean this up in the next version of the Discovery spec. In particular we should specify that both should be supported by all implementations to avoid interoperability issues, or just allow one (like JSON Pointers), but that would go too far at this point (non-editorial, impacting implementations, etc).

---

Preview | Diff

[farshidtz]

This is a big feature drop hidden inside an assertion. It doesn't put the assertion at risk because other implementations implement the other methods prescribed in the same assertion.

IMO, this should be a separate assertion and have two separate backing implementations.

[mmccool]

Discussed in Discovery call May 22, felt that testing was not consistent and it was not reasonable to conclude that this was "tested", not to add additional specification e.g. JSON pointer. Several related at-risk assertions also had to be removed if this one is - in addition to one that was NOT at risk going into CR, but that was about returning an error if the feature was not supported (which is non-sensical to include if there is no feature). This PR now comments out the entire section and makes related repairs to the TM and other mentions of custom sorting. Also, sorting by ID was specified as being in ascending order, which was implied by the default value of the now-removed sort_order parameter.