Improve reindex throughput by using batch-based processing

[punktilious]

Is your feature request related to a problem? Please describe.
Currently the reindex process involves a number of per-resource interactions with the database. Throughput could be improved by performing a number of these interactions using a list of resources instead of individual ones.

Describe the solution you'd like
The parameter values should be collected and submitted to the database using the fhir-remote-index implementation. Requires a refactor of the fhir-remote-index parameter logic so that it can be shared by both the fhir-remote-index and fhir-persistence-jdbc projects.

Describe alternatives you've considered
Keep as-is and accept current performance.

Acceptance Criteria

1. GIVEN a database loaded with a lot of data
   WHEN reindexing is performed
   THEN throughput using the new reindex implementation has improved

Additional context
A new project is warranted here because we want to keep fhir-remote-index small and not have it need to depend on fhir-persistence-jdbc, which pulls in a lot of dependencies.

[punktilious]

New project is fhir-persistence-param and is now the common way to store parameter values. In addition, issue #3676 is dropping support for Db2, and this involves removing much of the resource-reference code.

[PrasannaHegde1]

Tried updating an existing Patient resource by adding a new search parameter favorite-color, then updating the same resource by removing search parameter favorite-color, adding a new search parameter favorite-team and calling the $reindex operation. The favorite-color search parameter token value ID is removed from patient_resource_token_refs table as expected and the favorite-team search parameter token value ID got added to the table.
This is working as expected