Worker Versioning: Add visibility tags (and possibly API) to enable worker retirement discovery

[Sushisource]

We need a way for users to be able to understand when a set of workers can be retired because no more workflows require the version those workers support.

We'll also likely eventually use this to provide automatic notifications of some sort.

We could accomplish this more than one way, but, like we've done with the proto messages it probably makes sense to avoid duplicating the data in the existing BinaryChecksums search attribute while adding a new BuildIDs search attribute.

That also said, BuildIDs would be a much preferable name. After a little googling, seems ES supports aliases, so that seems a good direction.

It's also not clear that the set of all build ids which the workflow has used is sufficient for a user to simply issue a visibility query and learn everything they need to know. At minimum, you'd also need to know which version the last wft was processed with, but even that is likely insufficient. EX: Last WFT was processed with 2.1 but the graph contains 2.2. You could query and find no open workflows have used 2.2, but, you actually need 2.2 workers to make progress.

So, seemingly a combination of the version graph and the visibility data is required, which means either fetching both and performing this determination client side (eww, dupe), or creating a new API server side for this purpose (or augmenting the GetWorkerBuildIDOrdering api).

We could, of course, postpone this "fully correct" version, since the simpler visibility-only approach is sufficient for most cases