Support Dapr "standalone" applications

[philliphoff]

Tye currently assumes that all Dapr-ized services are intended to be invoked by other services (or by the Dapr runtime itself, in terms of receiving messages from subscriptions). This implies that all Dapr-ized services have an HTTP binding (in order to be reachable by the Dapr runtime). If a service has no HTTP bindings, no Dapr runtime will be started for that service.

However, not all services require that; some may only make outbound calls to other services, directly or via pub-sub (e.g. subscribe to and receive message from an alternative source, process them, then invoke another service via Dapr). In this case, while the Dapr runtime is still needed but the application may not expose an HTTP endpoint (i.e. intended for Dapr as it has no need). The Dapr runtime supports this scenario, by omitting the --app-port parameter on startup.

This change allows more nuance in the Dapr extension. The default behavior remains that, if a service has an HTTP binding, a Dapr runtime will be started for it, using that bound port. Otherwise, it will not. However, the developer can now override that behavior using a new per-service configuration setting. In addition, if a service has only a single binding, and that binding has no explicit protocol, it will be assumed to be HTTP for the purposes of Dapr-ization.

extensions:
- name: dapr
  services:
    app2:
      enabled: true
    app3:
      enabled: false
services:
# app1 will be Dapr-ized because it has an HTTP binding
- name: app1
  bindings:
  - port: 3000
  - protocol: http
# app2 will be Dapr-ized because it was explicitly enabled (but without specifying the `--app-port`)
- name: app2
# app3 will *not* be Dapr-ized because it was explicitly disabled above
- name: app3
  bindings:
  - port: 3000
  - protocol: http

This new per-service configuration section will also form the basis for other general Dapr settings to be overridden; this PR only allows the placement-port setting to be overridden.

Resolves #1172
Resolves #1178

[philliphoff]

Oops, this was not intended to be published until #1191 was committed, as it builds off of it.