Changes related to supporting Pager Duty as a receiver

[rajagopalanand]

This is for receivers:

• Uses a pattern similar to service discovery
• This will be used in Cortex as follows in ApplyConfig(..) in alertmanager.go - Will submit a separate cherry-pick PR for that. There are more changes than shown below

	am.secretsProviderRegistry = secrets.NewSecretsProviderRegistry(util_log.GoKitLogToSlog(log.With(am.logger, "component", "secrets_provider")), am.registry)
	// currently only one secrets provider is supported
	am.secretsProviderRegistry.Register(providers.AMPAWSSecretsManagerSecretProviderDiscoveryConfig{
		UserID: userID,
	})
	am.secretsProviderRegistry.Init() //initialize the registry

• There is one SecretsProviderRegistry per tenant
• Each SecretsProviderRegistry has 1..n SecretProviders but only 1 provider of each type. AWSSecretsManagerProvider, InlineProvider are examples of provider. A registry can contain many providers but only one AWSSecretsManagerProvider and one InlineProvider (and one each of other types in the future)
• Each SecretProvider is free to implement however but in this implementation AWSSecretsManagerProvider maintains 1 SecretsFetcher per SecretARN. I chose to do it this way because each SecretARN's lifecycle can be different and the AWSSecretsManagerProvider manages the lifecycle of all the fetchers. For example, if the same ARN is registered twice, AWSSecretsManagerProvider will only create 1 SecretsFetcher

*Corresponding Cortex Changes https://github.com/aws-observability/cortex-dev/commit/0278ebb20a6cf30090988e5d1a39dcff3a59f56d

[mustafain117]

I haven't tested the V1 integration end to end, wondering if we need to consider this in our canaries/tests.