Data race in CatalogManager::GetTableLocations

Saw this on a test run.

I think the problem is that TSInfosDict is reused for all calls to BuildLocationsForTablet for a particular table, and the map inside it points to peer UUIDs by reference (i.e. StringPiece) instead of by copy. Thus, when a given BuildLocationsForTablet call completes, the tablet lock is released and the catalog manager is free to destroy that tablet's TabletInfo (i.e. via committing a mutation in ProcessTabletReport). But the very next call to BuildLocationsForTablet may cause TSInfosDict map keys to be read and compared, even though the memory backing those keys no longer exists.

Assigning to Will because he committed 586e957f7 but cc'ing Todd Lipcon as he was the original author of the code.