Automatic deletion of old build output for no longer existing workspaces.

### Description of the feature request:

This feature request is primarily about **automatic** deletion of old workspace directories in the output root, which are associated with workspace locations that **no longer exist** in the file system.

If building such automatic deletion into bazel is too controversial, then an alternative could be to expose a formal interface where an external cleanup script could retrieve association from build output directories to workspace locations. That association is already provided in generated README files, but they states:

> The first line of this file is intentionally easy to parse for various interactive scripting and debugging purposes. But please DO NOT write programs that exploit it, as they will be broken by design: it is not possible to reverse engineer the set of source trees or the --package_path from the output tree, and if you attempt it, you will fail, creating subtle and hard-to-diagnose bugs, that will no doubt get blamed on changes made by the Bazel team.

### Feature requests: what underlying problem are you trying to solve with this feature?

Our users often create new git clones at various file system locations. After deleting the git clones, the associated build output remains "forever" and consume lots of space in their output root.

“Bazel clean” only deletes the current workspace.

Many users have limited knowledge about the output root, how the build output is stored for each workspace or what internal directories are safe to delete. I think bazel should solve this problem for them automatically.

### Have you found anything relevant by searching the web?

Related to #12902, but that one is **not automatic** and **delete everything** (also workspaces still working with).

#5139 touches on similar subject but is primarily about --disk_cache not build output in output root.

Start by reviewing Bazel's output-root and workspace-association behavior, then compare the related discussions in issues #12902 and #5139. The issue does not name files, tests, or entry points; completion would require a decided design for automatic cleanup or a supported external association interface, with coverage for workspaces that no longer exist.

Written by the indexing model from the issue text.