Standard Return types for each endpoint

[BryceStevenWilley]

Now that I'm wrangling with now with ECF5, we will likely need to work with ECF 4 and ECF 5 jurisdictions at the same time, and IMO, it's a very bad idea to try to expect all of the client implementations to compare and convert between the two, especially when they don't know which jurisdiction is using which. Our proxy wouldn't be very useful if we just continued doing what we're currently doing and passing through either the XML or the JSON-ized version of the XML.

We're going to need to have a (hopefully) relatively simple standard that we can put all of the data that we're using from ECF 4 stuff on docassemble and put it in our own JSON data type, one per endpoint. It can be extensible in a python-dict sense, so if something the client is looking for is there, it can use it.

[BryceStevenWilley]

Some background discussion of other solutions considered before this in #27

[BryceStevenWilley]

Ran into a slight issue with the "python dict" method described above; certain responses are as JSON lists, and I can't add arbitrary attributes like processed_data to a list like that. That means we'll have to do things the hard way, by actually versioning the API. Hooray.

I do like how GitHub does their API, and they recently switched to a date version that's in a specific header. TBH, we don't need things to be date organized, but I do like the idea of a version string in a separate header (not trying to muck with Accepts, which TBH java makes it difficult to work with). So, if we get headers that include a "2" (only need the major version, not patch or minor, and trying to have clients pass that (do ppl want to pin a patch version? Do we want to support that?) would get complicated), then we can just send them the new object.

Testing will be a bit, but we can make some unit tests that take standard responses and make sure they can always be returned as is or as the new return type.