refactor(plugins): formalize plugin and module type extension mechanisms

This adds framework native abilities to
A) define a plugin from a base plugin, and
B) explicitly create or extend module types.

Previously, there was no built-in notion of "base" plugins, so plugins
that wanted to duplicate another plugin had to do that directly at the
code level. This also meant that Garden had no idea whether two plugins
would be compatible, so it was not possible for a plugin to
depend on a base plugin and work with any plugins that inherit it.
For a practical example, that was why we needed a `local-openfaas`
plugin, that paired with the `local-kubernetes` plugin. Now any plugin
that depends on the `kubernetes` plugin _also_ works with any plugin
that inherits from that plugin, e.g. the `local-kubernetes` plugin.

We ensure this by enforcing that inheriting plugins use a configuration
schema that is compatible with the base plugin, either by making its
schema a superset of the base's schema, or by having its
`configureProvider` handler return a config that matches the base's
schema.

It is also now explicit whether a plugin is creating or extending a
module type, and we add a bunch of validation to
ensure it's all being done correctly.

This is arguably a feature commit, but I'm categorizing it as a refactor
because it doesn't immediately introduce user-facing features, and
rather opens the door for creating more plugins.

For example, we can now readily make more "special-case" versions of the
`kubernetes` provider, e.g. one for GKE, another for EKS and so on.

We can also make a variety of plugins that depend on the `kubernetes`
plugin, e.g. a Linkerd plugin, monitoring plugins etc., that can then
work with any flavor of the `kubernetes` plugin.

A following commit will add the same type of inheritance features to
module types, with analogous benefits.

For reviewing, I strongly recommend looking at the added tests first,
since they describe the intended behavior. Also look at the changes
made to the `openfaas` example, the `local-kubernetes` plugin and
the (now deprecated) `local-openfaas` plugin to see the changes in
practical context.

examples/openfaas/garden.yml

@@ -2,17 +2,14 @@ kind: Project
 name: openfaas
 environments:
   - name: local
-    providers:
-      - name: local-kubernetes
-      - name: local-openfaas
-        hostname: openfaas-gateway.local.app.garden
   - name: testing
-    providers:
-      - name: kubernetes
-        context: gke_garden-dev-200012_europe-west1-b_garden-dev-1
-        namespace: openfaas-testing-${local.env.CIRCLE_BUILD_NUM || local.username}
-        defaultHostname: openfaas-testing-${local.env.CIRCLE_BUILD_NUM || local.username}.dev-1.sys.garden
-        buildMode: cluster-docker
-      - name: openfaas
-variables:
-  my-variable: hello-variable
+providers:
+  - name: local-kubernetes
+    environments: [local]
+  - name: kubernetes
+    environments: [testing]
+    context: gke_garden-dev-200012_europe-west1-b_garden-dev-1
+    namespace: openfaas-testing-${local.env.CIRCLE_BUILD_NUM || local.username}
+    defaultHostname: openfaas-testing-${local.env.CIRCLE_BUILD_NUM || local.username}.dev-1.sys.garden
+    buildMode: cluster-docker
+  - name: openfaas