This type should have been moved originally.

Ignore dlls that come from a 'packages' directory when searching for viable metadata references to search.

We don't perform fuzzy searching in add-using for interactive.  This needs bk-trees
which are expensive to create, and which are not cached in interactive.

We also don't search for potential project/metadata references to add.  Adding
references for interactive is sufficiently different that we don't want to run these
codepaths unless we're doing the right thing for interactive.

This reverts commit 18d27544, reversing
changes made to 5925aaef.

The change being reverted was hte one to speed up add-using in the interactive
window. However, i'm concerned about potential perf problems this may cause in
the mainline add-using case. I'm reverting this for now until i can come up
with a fix i think is suitable for both.

This reverts commit 18d27544, reversing
changes made to 5925aaef.

1. When creating symbol tree infos, lazily produce BKtrees.  That way we don't
   take the perf hit for features that want to search but don't need fuzzy matching

2. Don't perform fuzzy matching interactive.  The problem here is that interactive
   Doesn't have a 'serialization service'.  As such, when VS loads and we run
   interactive, we end up having to produce all the same BKtrees for metadata again.
   In normal scenarios we can store these in the .vs file, so we only pay the price
   the very first time.  In Interactive we always pay the price the first time
   after VS loads.

Break SymbolReferenceFinder into its own class.  This makes the merge with another branch much cleaner.