Separate filter IDs from filter structs in /sync

Nobody has claimed this yet.

Currenlty the `/sync` endpoint accepts both a filter id and a json filter struct on the same `filter` field.

> The ID of a filter created using the filter API or a filter JSON object encoded as a string. The server will detect whether it is an ID or a JSON object by whether the first character is a "{" open brace. Passing the JSON inline is best suited to one off requests. Creating a filter using the filter API is recommended for clients that reuse the same filter multiple times, for example in long poll requests.

It seems like a hacky solution to the problem of one off requests because they are two completely different types that require different parsing. Also the implementation on a static type language will be a little awkward. Instead of overloading the `filter` field there could be two separate fields, one for filter IDs and one for filter structs.

Start by reading the `/sync` endpoint description and the filter API wording in this issue. Define separate request fields for filter IDs and inline filter objects, then update the specification so their parsing and one-off versus reusable usage are unambiguous.

Written by the indexing model from the issue text.