Adjust BB Logic to Enable ServiceMonitors, NetworkPolicies, and AuthorizationPolicies depending on which Metrics Scraper is enabled

Placeholder/Parent issue for Alloy and Prometheus metrics scraping logic.

Currently package logic to enable ServiceMonitor is wildly inconsistent across all packages. Additionally, AuthorizationPolicy and NetworkPolicy objects that are used for metrics scraping are usually created with a Big Bang internally managed monitoring.enabled key(some exclusions apply). Rather than trying to shoehorn logic to enable packages to be scraped by the new Alloy metrics collector instead of or at the same time as the Prometheus metrics collector, we should standardize and simplify this logic.

Currently, packages fall into one of a few categories:

1. ServiceMonitor is a upstream key, which allows setting values for that. Auth and net pols are created off the BB internally created monitoring key ex: alloy
2. monitoring is a Big Bang internally created key, which will trigger upstream chart logic to deploy a service monitor, net pols, and auth pols ex: kyverno reporter sm
3. monitoring is an upstream key, which will trigger upstream chart logic to deploy a service monitor. This is also used to trigger Net and Auth pol logic built by big bang engineers ex: gitlab
4. other wild card here if found

The cleanest solution may be to not use upstream ServiceMonitors at all, rather deploy Big Bang created ServiceMonitor with BB Common and utilize their Net/Auth pol functionality in tandem.