Update operator bundle to support specifying the mongodb connection

[carolynvs]

The kubernetes storage plugin relies on persisting documents in secrets. I think it will be a bit of work and hacks to make it support the new mongo storage plugin interface. The operator bundle should have a parameter for installing mongo in the operator namespace and using it for storage, or accepting a mongo connection string.

[bdegeeter]

I think an outputs section of the Installation resource is a great place to start with this idea. It aligns well with patterns seen in terraform and similar tools.

With the pivot to mongo for persistent storage, I could see an output having key to an endpoint in a variety of storage back ends similar to Argo.

Mentioned in https://github.com/getporter/operator/issues/41. Default could use mongo in the operator namespace. Perhaps the operator could proxy getting the output from the storage backend allowing a consistent interface to fetch outputs?

We are looking to have a catalog of bundles a user can deploy, accessible from a web interface or api. Ideally one can consistently get the output data from the bundle install and pass it along to the client/user without going direct to specific storage platform.

[carolynvs]

@bdegeeter I replied on https://github.com/getporter/operator/issues/42 to keep the conversation on the main issue (so that I can find it later!)