refactor: reimplement rpcapi in DRF

[jennifer-richards]

This reimplements the API in api/views_rpc.py using django-rest-framework instead of custom views. Removes the rpcapi.yaml file.

The API spec is now generated by running ietf/manage.py spectacular --file rpcapi.yaml. This generates the complete DRF schema, which includes both the red and purple APIs. These include tags in the schema that separate the PurpleApi from the RedApi.

A few changes were made to the API to make serialization easier. Notably

• Paths for the purple API are now /api/purple/... instead of /api/rpc/...
• The batch person name lookup now returns entire person records, not just name, and returns a list of records rather than a dict mapping ID to name
• Several APIs that returned objects like {"something": [<array of things]} now just return the bare array without the wrapping

There will be a corresponding PR on ietf-tools/purple that makes the necessary adjustments to work with this. Local testing shows it at least mostly works. I have not test with the rfced-xfer process, but checked fairly carefully that the APIs created for that process return the same results as before.

Several bits of CI / dev gearing expect to fetch the rpcapi.yaml file from git - we'll need to refactor those to create or find another way to manage that spec. We've already worked around this for the RedApi.

Important note: this makes a slight change to the validation on DocumentInfo.title, which is way out of scope. The reason for this is that the old validate_no_control_chars validator includes a regex with \x00 in it. This escaped NUL char is turned into a literal NUL char somewhere on the way into purple's API client, resulting in python source with an invalid character in it. The change here replaces that \x00 with a \0x1 and adds a ProhibitNullCharactersValidator to the title field which is the only place this validator is used. This adds a book-keeping migration.