What this PR changes/adds

This PR adds a RemoteStsAccountService which can be used in cases where the STS runs as standalone application. It uses the STS Account API to manage accounts.
Note that the StsAccountProvisioner was split up, so that the business logic remains the same, while STS accounts are managed "locally" (embedded) or "remotely" (using the STS Account API).

These services are implemented in a separate extension modules sts-account-service-local and sts-account-service-remote. If neither of these modules are on the runtime classpath then a NOOP service is used and a warning is logged.

The RemoteStsAccountService assumes that authentication against the STS Accounts API is done by adding a particular header, e.g. Authorization: XYZ or x-api-key: XYZ (default).

It does not yet support dynamic tokens, e.g. OAuth2. This is a known limitation!

Two new test runtimes have been added:

• :e2e-tests:runtimes:sts: a minimal, standalone STS runtime
• :e2e-tests:runtimes:identityhub-remote-sts: an IdentityHub that does not contain the STS but instead uses the RemoteStsAccountService
• cleaned up some obsolete files

Why it does that

feature parity with standalone STS

Further notes

• Authentication RemoteStsAccountService -> STS Accounts API is currently only possible using static tokens.

Linked Issue(s)

Closes #467

Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.