Proposal: hyper `Flag` service

With all of our customers, we advocate for trunk based development, and separating release from deployment; code ought to be continuously delivered, with features being shipped behind flags. The DORA metrics show that this is what high performing teams _do_.

Feature flags are so essential to this way of delivering, that it would make sense for the service framework to have a `Flag` service. The api would be really simple, basically a key-value store, but geared towards feature flags:

```ts
// Store api
create(name: string): Promise<{ ok: boolean }>
destroy(name: string): Promise<{ ok: boolean }>
// Flag api
get (name: string): Promise<{ ok: boolean, flag: any }>
set (name: string, value: any): Promise<{ ok: boolean }>
remove(name: string): Promise<{ ok: boolean }>
```

Since flags can be more than just booleans, it makes sense to allow the value to be anything. Maybe there are other apis, but this is simple, and general purpose, in the spirit of the framework.

This API could be implemented on _so many_ technologies -- practically anything that can store key-value pairs. A sqlite adapter would be enough for most teams. Adapters could also be written on top of SaaS like LaunchDarkly, but starting out that'd most likely be overkill.

Das Issue schlägt einen neuen Flag-Service vor, nennt jedoch keine Implementierungsdateien, Einstiegspunkte oder Tests. Beginne damit, die Service-Schnittstellen und die Adapterstruktur im Repository zu finden, und ermittle dann, wie eine allgemeine Flag-API und ein SQLite-Adapter dazu passen würden. Als abgeschlossen gilt die Aufgabe, wenn eine abgestimmte API, ein Implementierungsansatz und die entsprechenden Tests vorliegen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.