Schema key field format differs from Confluent SR

# What happened?

Karapace uses this order for the key fields in Kafka records: `subject`, `version`, `magic`, `keytype`.
In Confluent SR, it's: `keytype`, `subject`, `version`, `magic` ([code](https://github.com/confluentinc/schema-registry/blob/52305272e4ef994bd61222b05382bfbb10091b39/core/src/main/java/io/confluent/kafka/schemaregistry/storage/SchemaKey.java#L26)).

This difference is significant because Kafka topic compaction (normally used on the `_schemas` topic) doesn't parse these key JSONs and compare them as byte strings. If a schema was written by CSR and later hard deleted by Karapace (i.e. a tombstone record with the null value was produced), the compaction will not happen and the old schema definition will remain in the topic.

It seems, this should not affect soft deletion and other operations, because to apply them, the JSON is parsed. However, the compaction still won't happen.

# What did you expect to happen?

Karapace would use the same order as Confluent SR.