cli: provide environment override capability

[shashankram]

Description:
Provides the capability to override default namespace
and commands in osm cli. This is required to provide
a better experience of osm cli in managed environments,
where users can be advised to use a config file to to override
defaults.

It works as follows:

1. If osm config file is present, either in $HOME/.osm/config
   or specified via the OSM_CONFIG env var, this file will be
   used for environment defaults. This works similar to
   KUBECONFIG where the env variable overrides the static
   file if present.
2. If osm config file is not present, defaults values are
   used for the environment configurations.
3. If the install kind is set to managed in the config file,
   then install/uninstall/upgrade/dashboard commands which
   are only meant for self-hosted environments are disabled.

Part of #3978

Testing done:

1. When no config file is specified via OSM_CONFIG env var or $HOME/.osm/config:

$ osm env
--- 
install:
  kind: self-hosted
  distribution: ""
  namespace: osm-system

$ osm -h | grep osm-namespace
      --osm-namespace string   namespace for osm control plane (default "osm-system")

2. When OSM_CONFIG env var is used to specify a config file:

$ cat /tmp/osmconfig.yaml 
install:
  kind: managed
  distribution: AKS
  namespace: kube-system

$ OSM_CONFIG=/tmp/osmconfig.yaml osm env
--- 
install:
  kind: managed
  distribution: AKS
  namespace: kube-system

$ OSM_CONFIG=/tmp/osmconfig.yaml osm -h | grep osm-namespace
      --osm-namespace string   namespace for osm control plane (default "kube-system")

3. When $HOME/.osm/config is present and OSM_CONFIG env var is not set:

 cat ~/.osm/config.yaml
install:
  kind: self-hosted
  distribution: Kind
  namespace: osm-system

$ osm env
--- 
install:
  kind: self-hosted
  distribution: Kind
  namespace: osm-system

$ osm -h | grep osm-namespace
      --osm-namespace string   namespace for osm control plane (default "osm-system")

Affected area:

Functional Area
CLI Tool	[X]

Please answer the following questions with yes/no.

1. Does this change contain code from or inspired by another project? no

   • Did you notify the maintainers and provide attribution?

2. Is this a breaking change? no

[draychev]

This is excellent! Thank you!

[allenlsy]

I feel the solution is coupled with how a managed environment works. Suppose we have another managed environment using a new way of automation, we then need to provide more options.

But for now, this is the way to go.

[shashankram]

I feel the solution is coupled with how a managed environment works. Suppose we have another managed environment using a new way of automation, we then need to provide more options.

But for now, this is the way to go.

I don't understand this comment. If the install is managed (as specified in the config file), then there is no reason to give the users the option to install. What's the concern here?