ReferencedTabletFile has getTableId method that may be misleading.

In `ReferencedTabletFile` and inherited by `StoredTabletFile` there is a method
```
public TableId getTableId() ...
```

The id is being derived by parsing the file path. If a table had been cloned, the id in the path may not be the table id. At a minimum, the method could be renamed, and possibly return an id that is not a TableId so that any id derived from the path cannot be directly used as a TableId.

The issue would be if someone assumed that the TableId returned from a ReferencedTabletFile was the same a the "real" table id and then made metadata changes based on incorrect information. Just using the method signature, it seems easy to make an incorrect assumption on what that id returned represents.

Start by reading ReferencedTabletFile and StoredTabletFile, then trace callers of getTableId to see how the path-derived value is used. Clarify whether the API should be renamed or return a different identifier type, and consider the affected callers and tests; done means the API no longer suggests that a path-derived id is the real table id.

Written by the indexing model from the issue text.