Break out QA into a separate service

**What?**

Unlike datastore, I think QA is a viable candidate for breaking out into a separate service as there is no hard-requirement for it to be performant (not a real word, I know) and the bindings to CKAN could be conceptually looser than current implementations imply.

**Why?**

The ckanext-qa/ckanext-archiver combo is hard to set up and can consume a rather large amount of resource. More value can be provided to the wider open data community by opening up the QA processing.

**How?**

The QA Service should be easier to setup with a simpler interface to the caller. Having a separate service that responds to POST requests with asynchronous responses would provide value to others not using CKAN as well. QA/Archiver doesn't have any hard dependencies on CKAN (other than various branches writing direct to DB, or using the API) and could be modified to just POST a response in a known format.

The QA extension itself would just become a thin extension that would POST changes to a resource, and an API for receiving responses writing to a known extra fields in the resource.

Start by reviewing the ckanext-qa and ckanext-archiver implementations and their setup and CKAN dependencies. Define the separate service boundary, POST request and asynchronous response format, plus the QA extension's resource and extra-field integration; done means these interfaces and migration scope are agreed.

Written by the indexing model from the issue text.