remap osm-arc chart values to osm oss chart values

The arc extension will pass in a set of Azure specific values related to proxy (and potentially other values later on) at the time that a user installs the osm arc extension on their cluster. This happens essentially via a `helm install` with the osm-arc chart. You can think of the arc team is trying to do as `helm install --set Azure.httpProxy="something"`. The osm-arc chart installs the osm chart as a dependency( aka child) meaning it can override values of the child chart. The osm chart is where the proxy configuration is exposed via certain values. For example, one of the proxy settings in the osm chart is called `OpenServiceMesh.fluentBit.httpProxy`. We want to be able to set the value of Azure.httpProxy to OpenServiceMesh.fluentBit.httpProxy at install time.

Currently, there is not a clean solution for this:
- Moving these values both in the open source osm chart and the osm-arc chart to the `Global` key in the values files is 1) not a convenient solution for either project and doesn't clearly make sense for the oss chart 2) Not a solution that makes sense for the arc team as they plan to add more Azure specific values and don't want to dirty the Global key in arc extension's chart. PoC & further explanation [here](https://github.com/Azure/osm-azure/pull/49).
- We could use a Helm's [post rendering ](https://helm.sh/docs/topics/advanced/#post-rendering)functionality and kustomize or a custom bash script to overwrite the original templates that get rendered. This is not functionality that the arc team has at the moment and would require the arc team to enable usage of a post-renderer thereby adding an additional tool/dependency to the toolchain. This is also a somewhat brittle solution as it relies on keeping up pretty manually with any changes in the osm chart templates thereby putting extra work on the team. PoC [here](https://github.com/Azure/osm-azure/pull/48).

What we really need is something that is referred to in the Helm community as export-values functionality described [here](https://github.com/helm/helm/issues/3242). There is also a open PR for the feature in the Helm repo [here](https://github.com/helm/helm/pull/7477). It has been open for about a year now, so the next step on our part would be to engage with the Helm community to see how we can move this work along.

Start by reading Helm issue 3242 and PR 7477 to understand the proposed export-values behavior. Compare the existing proof-of-concepts in osm-azure PRs 48 and 49, then determine how Azure.httpProxy should map to the osm chart's OpenServiceMesh.fluentBit.httpProxy and related values. Done requires an agreed path with the Helm community, not just a local chart change.

Written by the indexing model from the issue text.