RAR is slow with lots of search paths

### Issue Description
Our caches for RAR store information about assemblies so that we don't have to open them to get the key information, but they don't store where those assemblies are. We still have to walk through the search paths to find them. In most cases, this isn't such a big deal, but some customers (as in #6911) have thousands of search paths, and searching all of them takes an inordinate amount of time. I don't know how common that case is, but it would be good to reduce that.

### Steps to Reproduce
Create a project with a huge number of search paths but only one assembly and measure how long RAR takes to execute.

### Data
See #6911.

### Analysis
I don't think there's a way to skip to where the assembly is without introducing some kind of breaking change—just because there is not an assembly at a particular path in one RAR execution does not mean that assembly will not appear there before the next. This proposal is for an opt-in (possibly opt-out, though I think opt-in is better at this point) feature to skip to the appropriate search path.

Specifically, we would create a new cache and serialize/deserialize it as we do for instanceLocalFileStateCache now. If we're looking for Foo, and it's at C:\myPath\Foo.dll, the cache would store that Foo is at C:\myPath\Foo.dll. We would _not_ follow the proper order of search paths, only falling back to that if Foo is not in the cache or we can't find it at C:\myPath\Foo.dll. The latter would also be the only case in which we would evict Foo from the cache.

### Regression?
No