Move VERSION_HISTORY to fhir schema and retire FHIR_ADMIN schema

[lmsurpre]

Is your feature request related to a problem? Please describe. I wanted to bootstrap a deployment with different users for fhirdata and java batch.

java -jar /opt/fhir-server/tools/fhir-persistence-schema-*-cli.jar --create-schema-fhir --update-schema-fhir --grant-to fhirserver ...
java -jar /opt/fhir-server/tools/fhir-persistence-schema-*-cli.jar --create-schema-batch --update-schema-batch --grant-to fhirbatch ...

However, it failed immediately saying that the FHIR_ADMIN schema doesn't exist. The --create-schema-fhir, --create-schema-batch, and --create-schema-oauth options are pretty useless if they require the FHIR_ADMIN schema to exist because, currently, the only supported way to create that (from the tool) is to use --create-schemas which creates all four.

Describe the solution you'd like Implicitly create the admin schema when any of the --create-schema-x actions are specified.

Describe alternatives you've considered Introduce an explicit --create-schema-admin option

Acceptance Criteria

1. GIVEN a new database WHEN --create-schema-fhir fhirdata THEN two schema are created: fhir_admin and fhirdata

2. GIVEN a new database WHEN --create-schema-batch fhir_jbatch THEN two schema are created: fhir_admin and fhir_jbatch

3. GIVEN a new database WHEN --create-schema-oauth fhir_oauth THEN two schema are created: fhir_admin and fhir_oauth

Additional context Currently, I think the --create-schema-fhir cannot be done together with --update-schema-fhir...I opened #3810 for that.

[lmsurpre]

Robin's proposal: now that we've dropped support multitenant schemas, lets drop the FHIR_ADMIN schema altogether. We can put the existing CHANGE_HISTORY table directly in the FHIR schema (alongside the "whole schema version").

[lmsurpre]

impl hint: CREATE TABLE fhirdata.version_history AS SELECT * FROM fhir_admin.version_history