Sparql Adapter System

### Version

5.7.0-SNAPSHOT

### Feature

This is the proposed sub system upon which execution tracking for both local and remote datasets can be based.

### SparqlAdapterRegistry

The core idea is to introduce an indirection for sparql query and update execution.
The central class is `SparqlAdapterRegistry` which is a container for `SparqlAdapterProvider` instances:

```java
public interface SparqlAdapterProvider {
SparqlAdapter adapt(DatasetGraph dsg);
// Perhaps rename to "createAdapter" to avoid confusion with "adapt" methods in presentation layer classes.
}

public interface SparqlAdapter {
QueryExecBuilder newQuery();
UpdateExecBuilder newUpdate();
}
```

The main changes in `QueryExec` are as follows:
```java
public static QueryExecBuilder dataset(DatasetGraph dataset) {
// Consult the registry to obtain an adapter implementation for the supplied dataset type.
return SparqlAdapterRegistry.adapt(dataset).newQuery();
}

public static QueryExecDatasetBuilder newBuilder() {
// We don't know the dataset yet, so adapter selection needs to be deferred until build().
return QueryExecDatasetBuilderDeferred.create();
}
```

### Deferred Builders

The subsequent change is the introduction of a `QueryExecDatasetBuilderDeferred`, which chooses the right adapter during build. Conventionally, it will obtain the SparqlAdapter for the default query engine, obtain its QueryExecBuilder and transfer its own settings to it.
The change for `UpdateExec` is likewise.

Major changes - For most users these should be source code compatible but they may not be byte code compatible:

* `QueryExecBuilderDataset` is now an interface. The original implementation is `QueryExecBuilderDatasetImpl`. The new one is `QueryExecDatasetBuilderDeferred`.
* `QueryExecHTTP` is now an interface. The original implementation is `QueryExecHTTPImpl`. The new one is `QueryExecHTTPWrapper` which can apply execution transformtions.

### Exec Transformation

* `QueryExecBuilder` now features a `transformExec(Function qeTransform)` method. This allows for post-processing the QueryExec being built without having to change the builder type. One way to add execution tracking via builders with preconfigured transforms. Alternatively, the builder itself could (in addition) include logic that consults the context for any post processing to apply to QueryExecs.
* `UpdateExecBuilder` likewise.

### Are you interested in contributing a solution yourself?

Yes

Start by reading the existing QueryExec and UpdateExec builder APIs, then trace how DatasetGraph instances currently select query and update execution. Review the proposed SparqlAdapterRegistry, deferred builders, and execution transformation interfaces. Done would mean an agreed implementation of the proposed subsystem and its source-compatibility behavior; the issue does not name tests or files.

Written by the indexing model from the issue text.