Allow for Runtime and App Separation

[IfSentient]

Currently, an app is built targeting a specific runtime--the only available one being an operator with kubernetes webhooks (though custom functionality can be layered on top). To better allow apps to be targeted for different deployment types, such as an API server, or running entirely as a multi-tenant (or even single tenant) plugin, or in the future as other runtimes such as WASI, the logic for what an app can do (Control loops, Admission, Conversion, etc.) should be split from how this functionality is called (webhooks for admission/conversion, or inlined in an API server, for example).

The proposal for this is to define an app interface which describes behavior, and runners which can then run the app based on how app interactions from "outside" should be handled (for example, how does a validation request get to the app).

type App interface {
    // App interactions, including, but not limited to:
    Validate(ValidationRequest) (bool, error)
    Mutate(MutationRequest) (MutationResponse, error)
    // ...etc...
}

type AppProvider interface {
    Manifest() AppManifest
    NewApp(AppConfig) (App, error)
}

Runners then consume an AppProvider, and handle initializing the app by providing it with config data, including kube config, which are based on the runtime manner (for example, an API server would use the loopback config, or an Operator would use the config for the API server).

This requires the existence of the App Manifest as described in #353