Avoid creating unnecessary tables for Resource and DomainResource resource types

[lmsurpre]

Describe the bug
Follow-on from #623

What about Resource_LOGICAL_RESOURCES, DomainResource_LOGICAL_RESOURCES, Resource_RESOURCES, and DomainResource_RESOURCES tables...are we generating those tables? Do we need them?

John tried to remove these, but something must be trying to use it because he saw a ForeignKeyException that he traced back to these missing tables.

To Reproduce

1. deploy the schema
2. look at the tables

Expected behavior
Abstract resources shouldn't have resource tables.

Additional context
The way its designed, we'd need to special case these somehow. Is there a cleaner way?

[lmsurpre]

I added an "includeAbstract" boolean argument for ModelSupport.getResourceTypes() and so we could probably use that to avoid getting Resource and DomainResource. The hard part is investigation whether these tables are really used presently and why...

[lmsurpre]

Robin found the offending lines: https://github.com/IBM/FHIR/blob/main/fhir-persistence-jdbc/src/main/java/com/ibm/fhir/persistence/jdbc/dao/impl/ParameterVisitorBatchDAO.java#L185-L204

It seems to be designed such that search parameter values with a base of Resource will be stored to these tables. However, it turns out that we never actually set the ExtractedParameterValue base (except for component params) and so they're never actually used. Furthermore, Robin points out that these RESOURCE_XXX_VALUES tables have a foreign key to the RESOURCE_LOGICAL_RESOURCES tables which are never populated...so its definitely not a usable design. This should get cleaned up as part of #1921.

[lmsurpre]

Question: Should we remove these unneeded tables as part of schema migration?

team decision: yes. but we should ensure there is no data in these tables before we delete them. if there is data in these tables somehow, then fail the upgrade. (or finish the upgrade and just log as warning?)

Question: what to do with the corresponding entries in FHIR_ADMIN.VERSION_HISTORY ?

options:
A. add an audit trail to document what has been executed, and remove the corresponding rows for these tables in VERSION_HISTORY
B. just write the new version to this entry in the VERSION_HISTORY table and that version will mean "its deleted" for these particular tables. The concern here is that we want a freshly installed schema to look the same as a migrated one.

[lmsurpre]

bumping to a P2 because, now that we are publishing multiple versions of all us-core and carin-bb search parameters, we get A LOT of warnings (on each request) if those are installed and the user hasn't disambiguated the versions.

[d0roppe]

verified that the targeted tables are not created in a update-schema, and are removed when issuing an update-schema on an older schema definition.