Aggregated API Server

[IfSentient]

In addition to being able to build an operator for one or more kinds, the SDK should allow for simplifying building an aggregated API server with no more codegen than it takes to build an oeprator (i.e., only necessary codegen is the kinds themselves).

The aggregated server should fully abstract away the CRUDL details from the app author, such that they simply specify the kinds, and an interface which is to be used for storage, and the routes and management are automagically set up. Admission control with validation and mutation should use the same interfaces as when using the webhook, but be inlined into the admission routes. Similarly, conversion should be handled inline. This doevtails into #150 in some ways, in that creating an aggregated API server should have a roughly similar interface to the simple operator.

Reconcilers/Watchers should be a part of the aggregated solution, and an app author would still be writing the business logic of the app the same way whether they're using a standalone operator or an aggregated API server.

This is a large task which will be broken down into subtasks as the work is split into manageable chunks.

[IfSentient]

Exploration of this is currently in the apiserver-poc branch.