The recommendation tests can be run in parallel but were in an assembly which
had many other tests that could not. Splitting out into a separate assembly
which is designed for parallel runs.

Fixes #2544.

The blocking waits can cause deadlocks because they potentially depend
on STA items.  Made the tests appropriately async.

Fixes #5730

Instead of truncating at 15 characters, we limit the (pixel) width of
the names, allowing WPF to truncate with "..." appropriately.

The ForegroundNotificationService is a shared resource when it is
accessed as an exported MEF component.  This means it's possible for
other components to still be posting messages to the work queue from
background threads.  This is exactly how some of the asynchronous
taggers behave.

As it is a shared resource tests which look to see if the work queue is
empty are inherently flaky.  There is no reasonable way to control it.
The fix is to create a non-shared service for this particular set of
checks.  This makes it possible to check definitively if the work queue
is empty.

Fix a couple of issues in the 64 bit queues

- Conditionally disable tests that have flaky behavior on 64 bit
- Disable interactive tests on 64 bit.  They are x86 only assemblies.
Will follow up later to see why they were ever passing in 64 bit mode.

Moved many of the blocking waits to await in the test infrastructure.
This resolves the remaining sources of observed instability in the
tests.

Moved many APIs to async which contained wait calls.  Forces developers
to use async now in tests when appropriate.

This change moves a good chunk of the IDE suites to be async.  This is
necessary in order for them to correctly pump and wait for tasks in the
STA environment.

The WpfTestCase pump now correctly interleaves pumping dispatcher
messages and moving the StaTaskScheduler queue forward.

This change makes foreground scheduling code predictable in the IDE
tests.  Instead of using a static to hold the data we use instance
values.  The static data the instance values are populated from are not
100% predictable but far more so than they used to be.

These tests were essentially deadlocking because the current scheduler
here is the StaTaskScheduler.  When the original thread hit the Wait
call the inlining code in the scheduler allowed the Task created in the
method body to run inline on the original thread.  This quickly lead to
a deadlock as both threads ended up waiting for each other in a blocking
fashion.

Fixed this by forcing the Task in the method body to run in the thread
pool.