Support per-config configTracker disable via ConfigMap/Secret annotation

[stealthybox]

This allows a user to annotate a specific ConfigMap or Secret to be disabled/ignored via the
configTracking logic that tracks config changes makes configuration copies for the primary Deploy

This is the minimum implementation necessary to support the use-case of using the same db or apiKey
secret for a Canary target. This allows these Secret values to change without triggering a new
Canary analysis. One example where this is helpful is with systems that auto-provision and rotate
secrets. Note the secret manager needs to be able to configure and preserve the flagger specific
annotation.

Annotating a configmap/secret will affect all Canaries with targets referencing them the same way.
Per Canary and per Target API's were discussed but seemed excessive.
We could not think of many scenarios where you would want to enable config-tracking for a specific
config in one workload but disable it for that same exact config in another workload.
It is still possible to implement these per-workload API's on top of this simpler mechanism in the future.

Closes #435

[stefanprodan]

@stealthybox do we test if the disabled configs make in the primary deployment unchanged?

[stealthybox]

@stefanprodan thanks for noticing -- this was bugging me in the back of my head for the past few days.
I think I got lazy last week because the test didn't already have any structure to loop through volumes, mounts, etc.

I just added the relevant positive and negative checks for primary Volumes.
I skipped VolumeMounts because a real apiserver should fail a template spec that doesn't have matching volume names. The mock client doesn't do this sort of validation, but I'm pretty sure our e2e tests that run on the CI kind clusters would.
What do you think?

[stefanprodan]

LGTM

Thanks @stealthybox 🥇