[main] Add new method to track originating cluster of Backup

[mallardduck]

This partial solves for #612

However it's important to note that while I wrote an RFE for this too - the root here is seeking to fix a bug. The bug is that "BRO itself doesn't do anything to give indications when In-Place Restore is acceptable to use".

The short version of the fix, is we add a few new status details and expose them via kubectl. And later make a change to rancher/dashboard to ensure UI can also benefit from this new context by adding a column.

---

To be discussed:

• This change is very Backwards Compatible, can we ship a CRD change for the new status field in a 2.10.x release?
  • Feels like it's a grey area - but, probably OK.
  • k8s seems to be OK with full on schema additions (of spec too) as long as they're optional/nullalble. This is hopefully less impactful since users cannot control status.
  • The current result on a cluster w/o CRD change is:
    • is a new warning about originCluster not existing on status,
    • Status conditions are correctly set to represent unknown in-place viability.
• Do we want to explore supporting an even more Backwards friendly method of detecting origin ID's with Filename?
  • For the best UX, we will account for existing backups with UID in filename. In other words, once the CRD is updated with new status field we'll add the UID we find from the filename (or do nothing if not matching expected filename format).

[mallardduck]

@jbiers - So i'm not moving it to in review yet, since this was a very rough first pass try.

However if you can take some time to get familiar with the changes and review the list of concerns I thought of (as well as consider/add your own) - that'd be great help to keep the ball rolling on this. In other words, while I could work on this more I'd love your feedback first before I spend more time on it.