feat: automatically create Kubernetes Services for apps using a https…

…erver component

One advantage of wasmCloud applications is that we always know what
components make up an application and therefore can intelligently make
decisions based on what interfaces we're using. This makes it much
easier for software like the operator to take particular actions based
on the contents of an application manifest.

This change adds an additional set of reconciliations we can perform on
a per-lattice basis to automatically create Kubernetes Services for
applications that deploy a httpserver component. The operator uses a
NATS consumer that watches for manifest deploy and undeploy events and
triggers a reconciliation on a managed Service. Right now this is
restricted only to `daemonscalers`, since we do not have to do any
bookeeping on where components are deployed if they are running on all
of the hosts in a lattice or in a subset identified by label. We will
add support for `spreadscalers` in a future PR.

This allows for some interesting deployment scenarios, such as wasmCloud
applications that span multiple Kubernetes deployments in the same
namespace, or potentially in _multiple namespaces_ if we decide to
implement support for them. Initially the operator is only creating
endpoints that route traffic from a service to pods in the same
namespace, but we may add an option to relax that assumption.