feat: comparison with nil fields

[scottd018]

Consider the following input YAML manifest:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: "letsencrypt-staging"
  creationTimestamp: null
  annotations:
    cert-provider: my-provider

Which produces the following go structure:

		Object: map[string]interface{}{
			// +operator-builder:resource:field=certProvider,value="letsencrypt-staging",include
			"apiVersion": "cert-manager.io/v1",
			"kind":       "ClusterIssuer",
			"metadata": map[string]interface{}{
				"name": "letsencrypt-staging",
                                "creationTimestamp": nil,
				"annotations": map[string]interface{}{
					// controlled by field: certProvider
					//  +kubebuilder:validation:Enum=letsencrypt-staging;letsencrypt-production
					//  Certificate provider to use.  Use one of: letsencrypt-staging or letsencrypt-production.
					"cert-provider": "my-provider",
				},
			},

This could be from a user who copied a YAML directly from another Kubernetes cluster. In this situation, the creationTimestamp field is directly controlled by the Kubernetes controllers. This is fine for applying to the cluster, but if we are comparing the desired state, we should ignore these fields.

Additionally, the ignoring of these fields should come at creation time, not during reconciliation. This means that we should do one of the following:

1. Error out during creation of resources and explain to user to fix their YAML
2. Forcefully strip out known "uncontrollable" fields and generate YAML that way

During discussion with @lander2k2 we decided it is best to implement the following:

1. Error out during creation of resources
2. Notify user that they can provide a --remove-fields flag or a --keep-fields flag that will either remove the known problem fields or keep the known problem fields. This would be up to user discretion to make the choice

Fields to ignore, for first pass, should be the following:

• .status
• .metadata.creationTimestamp
• .metadata.ownerReferences
• .metadata.generation
• .metadata.resourceVersion
• .metadata.annotations['deployment.kubernetes.io/revision']
• .metadata.annotations['kubectl.kubernetes.io/last-applied-configuration']

These fields should exist with in a library and be expected to grow over time.