The existing mappings on the ServiceBinding resource were introduced as
a way to make it easier for a user to enrich an existing Secret into a
form appropriate for binding to an application workload. This approch
had a few issues that can be better addressed by other resources that
interoperate with the ServiceBiding resource. The issues include:
- the ServiceBinding controller needs to be able to read and write
  Secrets
- Go templates were used to compose new values, which worked for basic
  templating, but were limited in their capabilities
- the capabilities of the Go templates are an implemenation detail of
  how the controller is built and could change over time independent of
  the speced behavior.

The behavior applied by mappings can be reintroduced as dedicated
resources that can themselves expose a Secret as a ProvisionedService,
which can be consumed by a ServiceBinding. This change further separates
the concerns of provisioning a service from binding a service.

Refs servicebinding#145

Signed-off-by: Scott Andrews <andrewssc@vmware.com>

Signed-off-by: Scott Andrews <andrewssc@vmware.com>

While bring back these fields and the general capability, I removed
references that mandated these fields be added to a Secret. Instead, the
requirement is that they are part of the application projection.
Implementors can figure out the best way to make that happen, either by
creating a derivative Secret, or by using a projected volume.

Signed-off-by: Scott Andrews <andrewssc@vmware.com>