Global Search Indexing - Support multiple namespaces and more flexible target type definition

**Motivation**
The default base and vocab project values are fixed on the current API, namely:
```
base: https://{nexus}/v1/resources/{org}/{project}/_/
vocab: https://{nexus}/v1/vocabs/{org}/{project}/
```
For projects that do not configure these values, when attempting to configure Global search to select the types that should be indexed or to traverse the RDF graph to collect the information to be indexed, one cannot make use of wildcards or path alternatives because:
1. the collection of types to be considered for indexing with CompositeView is fixed
2. the SPARQL query does not have a pattern to replace for the `{project_vocab}` like we have for `{resource_id}`

When global search is configured for a Nexus instance, Delta automatically provisions a CompositeView to be used by Global Search for any new project, or any project that doesn't have one configured. Because the base and vocab values differ and there's no templating for the SPARQL query wrt `{project_vocab}` there's no possibility to properly index data.

There are 2 courses of action to be considered:
1. modify the base and vocab defaults to use values that are common to all projects; this would allow the generation of a CompositeView that's independent of the target project
2. allow wildcards or templating to the collection of resource types considered in CompositeViews along with templating of the CompositeView SPARQL query for the project base and vocab
3. support indexing pipes to all implemented views such that a graph normalisation can be configured before the SPARQL query is executed

Regardless on the course of action, the search configuration needs to be able to normalise the variation of type (or any field that is an uri) such that ElasticSearch aggregations continue to function and there will not be a cardinality explosion of available values.

Option 3 seems valuable on its own.

**Acceptance criteria** TBD
1. When user selects...
2. When performing this api call...