What would you like to be added:
Finer grained control over the custom resource endpoint.DNSEndpoint to allow all types of record to be created by that resource. One way of creating an x509 Certificate with cert-manager is to use the DNS01 Challenge which requires the creation of a TXT record. It would be a significant improvement to the external-dns<->cert-manager interoperability if we could create TXT record with this custom resource.

Essentially, I'm proposing three changes to endpoint.DNSEndpoint:

1. An optional field in the spec to specify whether the record should store the status in the status sub-resource (for backward compatibility)
2. Adding a Finalizer to the Resource to allow the control loop to delete records that are marked to be deleted
3. Add a fields to the sub resource status to keep track of the records as they should be in the provider

type DNSEndpointSpec struct {
	Endpoints []*Endpoint `json:"endpoints,omitempty"`
	
	// +optional
	StoreStateInResource *bool `json:"storeStateInResource,omitempty"`
}

type DNSEndpointStatus struct {
	// The generation observed by the external-dns controller.
	// +optional
	ObservedGeneration int64 `json:"observedGeneration,omitempty"`
	
	Records []DNSEndpointRecord `json:"records,omitempty"`
}

This way, the control loop could work essentially the same way as it does now, but instead of fetching records from TXT records or DynamoDB, it could look at its status' subresource to validate the state of the record on the provider's side. This would allow the DNSEndpoint custom resource to support TXT records the same way it does everything else.

The deletion of a DNSEndpoint custom resource would be guarded by a finalizer. The control loop would check for the customRecord.ObjectMeta.DeletionTimestamp.IsZero() and if the value is not zero, it would attempt the deletion on the provider's side, then remove the finalizer to let Kubernetes gracefully remove the custom resource.

One thing to note is that the StoreStateInResource is an optional field, which means that if a custom resource doesn't have this value set to true, the custom resource would not store the state in the sub resource and would still use the normal route (TXT,dynamodb,noop). As a result, TXT records would only be supported for endpoint.Endpoint that have that value set to true. This was only added by me to add some level of backward compatibility for the current behavior.

Why is this needed:
All types of Records could be supported, which means it would allow folks like me to create TXT record to use external-dns with cert-manager to create x509 certificate through DNS01 Challenge. Those challenge requires to create a TXT record with a special field that proves the zone is owned by the one requesting the certificate.

I believe this change alone would allow me to use external-dns for creating DNS01 challenge. I am also interested in creating the PR to get this implemented, but I believe starting with a conversation might be the best option, right now.

I'm sure there are things I'm overseeing, but I believe this has enough information to at least get a conversation started.