VolumeManagerImpl proxying convenience methods around Volume/FileSystem operations need reviewed

The VolumeManager interface has a bunch of convenience methods, like `delete` and `create` and `globStatus` that perform the same operation on the underlying Volumes that it manages. However, these behave inconsistently, and are used inconsistently. In some cases, calling one of these methods means we want to perform that function on *all* volumes the VolumeManager is managing. In other cases, we may want to only perform it on a specific Volume's FileSystem once. The FileSystem may already be known if the parameter is passed as a Path object or a String that represents a fully-qualified Path. In other cases, it may be arbitrarily chosen by the VolumeManager.

At least one bug was found and fixed (in Tablet) in PR #1738 in the main/2.1.0-SNAPSHOT branch, pertaining to the use of globStatus. Others may exist that are similar.

In many cases, the right thing to do may be to remove these proxying methods. In other cases, we may want methods renamed to be more clear, such as `deleteEverwhere(String path)` or `createAnywhere(String path)`.

Start with the VolumeManager interface and VolumeManagerImpl convenience methods for delete, create, and globStatus, then review how Tablet uses globStatus in PR #1738. Compare whether each operation should target all managed Volumes, a known FileSystem, or an arbitrary one. Done means the proxying behavior is made consistent, or the methods are removed or renamed clearly, with similar bugs addressed.

Written by the indexing model from the issue text.