State.typeLocators map contains key/value pairs like
"InspectTests=src/InspectTests.java", where the value is FQN of the top
level type in binary notation, and the value the file path where the
type is defined, relative to project.

removeLocator(typeLocatorToRemove) used to iterate over values from
"typeLocators" map. This iteration over values of typeLocators map costs
lot of time for big projects, so with commit
7764772c16a268ab0f81abb866119b541b2ffb60 we made a wrong assumption that
we can avoid values iteration via reverse lookup with the key
constructed by the value.

This however doesn't work if there are sources with multiple top level
types defined in the same java file. Not all keys in typeLocators for
such types can't be re-constructed from values, and this leads to the
inconsistent state of the map, so that it contains more values as
another, "references" map, which keys are the values in the
"typeLocators" map. This is a problem due optimized way of persisting
the State to disk, where we iterate over keys of "references" and create
indices for them, so that we can avoid saving values of "typeLocators"
again, instead we just save indices. Here if we have less indices in
"references", we fail to find right index for "leftovers" in the
"typeLocators" and fail with NPE trying to persist a null index.

The solution is unfortunately to go back to iteration over map values
for removal of "typeLocators" values. Fortunately, the overall
performance is still way better as doing this with SimpleLookupTable.

Change-Id: Ia6e8090e42952056e73368f804d79e52c92111e2
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>