MAGN-5031 Watch3D is not previewing upstream geometry

This pull request resolves issue MAGN-5031 in which watch 3d nodes are not previewing their upstream geometry. The first step in fixing this was to see why our VisualizationManager tests were not catching this failure. Turns out, they were all marked as "Failure" so they weren't being run. They were all failing because the geometry library was not properly initialized for these tests.

## The Problem:
Watch3D components are not previewing their upstream geometry. This is because the code that originally fed upstream aggregated render geometry to these views is no longer wired-up. In its place is a connection to the data bridge which only grabs the graphic items from the incoming node, not the correct upstream representation.

## Fix Part 1:
Add geometry library initialization to the setup method on the test base class so that the geometry library starts. This fixes most of the tests. 

## Refactor 1:
We add a test services library and add a base class for geometry-based tests. This isn't actually part of the direct solution to MAGN-5031, but a refactoring that will make it much easier for third party developers to create tests which use the geometry library.

## Refactor 2:
We merge the RevitNodeTestBase and GeometricRevitNodeTest classes so all RevitNodesTests now start the geometry library (most of them were already and we had frequent mis-uses of the two base classes).
 
Requires Merge:
- [ ] Revit2015

PTAL:
- [x] @Benglin (I believe MAGN-5031 was not broken by the scheduler work, but we need to remove all the old rendering code because it's crazy difficult to debug rendering still among all the dead code.
- [x] @Steell (The internal issue has been flipped to you for input on the data bridge. Please read more in the issue details.
I actually collapsed these into one Setup method before, but then I thought twice. The reason to have them separated is that someone who makes a class that inherits from this class can choose to override any one of the SetUp methods. In this case their order doesn't matter. Of course if the order were important, we'd have to put them in one method.