For new ServiceBindings there's conflict where the ServiceBinding in the
informer does not have the binding secret resolved yet. When it tries to
update the workload with the projection, the webhook intercepts the
request and re-applies the binding. However, the resolved secret for the
binding is only on the local copy of the ServiceBinding being reconciled
as it has not yet been written to the API Server. Because it appears to
the webhook that the ServiceBinding does not have a binding secret, it
removes the projection the controller is trying to add.

This would be a nearly invisible annoyance except that the reconciler
compares the update request sent for the workload with the value
persisted caching the diff. That diff is then re-applied to the workload
resource the next time the ServiceBinding is reconciled, and if the
request would result in a no-op, the update is suppressed.

To side-step this issue, when the name of the binding secret changes, we
halt processing the remainder of the reconciler and update the status of
the binding with the resolved binding secret name. When this update is
received back by the informer, we continue with the reconciler. At this
point the webhook will have the secret name available to it and will not
undo the binding.

Signed-off-by: Scott Andrews <andrewssc@vmware.com>