Add schema syncing implementation

[andrewstucki]

This adds a high-level schema syncing client for CRD --> schema creation. Here's how it roughly works:

1. A user calls Sync with the CRD
2. The client pulls both schema data and compatability levels and merges them into a comparable in-memory object.
3. The client also pulls a special SchemaHash field on the CRD status which is just a non-cryptographic hash of the contents of the schema text string that has previously been synced (since the Redpanda schema creation operations have some normalization of the schema string and may no longer be 1-1 comparable with what's in the CRD)
4. All of these values are compared against what's currently in the schema CRD itself
5. If anything changes, then we create a new schema version and hash the contents of its schema text, returning both all of the version numbers of the schema and the hash of its contents.
6. The above will be used in patching the status of the CRD with both the hash of the schema and all of the versions of the schema that we've created in the registry.

Delete operations simply delete every version of the schema by their subject, and since a CRD deletion should leave things in a clean state, it issues both a soft and then hard delete.

This is the second broken-out piece of #263 with only the controller implementation and acceptance test additions remaining.

[chrisseto]

Nothing blocking

[chrisseto]

Will this need to be idempotent (Should it eat not found errors)?

[andrewstucki]

The general pattern I've followed most places is to just return the error from the client and then swallow it if we so desire in the controller by saying, "hey this is a non-retryable 'terminal' error while we're trying to clean up, so just ignore it"