Change strategy for getting osdu connection info

As per issue#32. Partition Secret Management should not be cloud vendor specific. So to address that MR92 was merged into master sometime back which is causing the Azure env to break. In this MR the cloud specific code was moved to a library and was dynamically loaded at runtime based on the ENV CLOUD_VENDOR, although we could not find the cause as to why it breaks the Azure env but we were getting "Connection refused to 169.254.169.254" which works otherwise from the ETP server pod and also versions prior to this MR.

So while working to find the cause, I tried another approach in which we can move Cloud provider code into separate modules. As a part of that below changes were done:

1. Moved the OSDU Connection retrieval part to a separate class inside Cloud Providers, oes::providers::OsduConnectionInfoProvider.
2. Added two separate abstract classes inside Cloud Providers folder to retrieve Secrets and Bearer token, namely BearerTokenProvider and SecretsProvider. Both of these can be implemented by any new cloud provider to provide Bearer token and secrets.
3. For instantiation of the above classes added two factory classes, namely TokenProviderFactory and SecretProviderFactory. It can be used as below:

std::string bearerToken = TokenProviderFactory::GetBearerTokenProvider()->GetBearerToken();

Similarly:

std::string secret = SecretProviderFactory::GetSecretsProvider()->getSecret("secretname");

For a new implementation, we can instantiate the required implementation from oes::providers::TokenProviderFactory::GetBearerTokenProvider.

4. Also a helper function to convert from CLOUD_VENDOR to its corresponding enum can be found inside EnvironmentResolver class.
5. Moved the azure specific implementations inside Azure namespace
6. Similarly, the interface exists in oes::providers namespace where as the implementation is inside the cloud namespace. Same can be done for any new implementations.