googletest git repository was using the SSH protocol
instead of HTTPS, which requires users to add an
ssh_key on github.com.

We switch all those external projects to HTTPS protocol,
but keep the ones hosted by ourselves on gitlab.kitware.com
in SSH since we might be contributing back to those
during development.

Add testing framework

Add testing with google test framework in the superbuild.

See merge request !104

Update Geometry and Sphere to have scaling and
radius respectively > 0;

With the superbuild architecture, the inner project
is not added as a subdirectory in the superbuild project,
but configured through ExternalProject_Add(). For this
reason, the CTestTestfile.cmake at the top level (superbuild
project) does not add the Innerbuild directory in which
there is another CTestTestfile.cmake referencing the tests
of the inner project.

This commit includes the file `imstkCTestAddInnerbuild.cmake.in`
which calls `subdirs()` on the Innerbuild directory. That file
is configured in the top-level build directory, and added as
the TEST_INCLUDE_FILE property to that directory. This will
include that file to the top-level CTestTestfile.cmake, which
will therefore be able to reach the CTestTestfile.cmake in the
Innerbuild directory when running ctest.

Use this commit to also only solve external dependencies
in the superbuild tree, no need to to it in the innerbuild tree.

By adding testing source files in the same directory
than the target source files, those first ones were
included in the target executables by mistake.

ctests would currently only be created for each test file,
but the GTEST_ADD_TESTS function[1] could allow to register
all gtests as independent tests.

[1] https://cmake.org/cmake/help/v3.0/module/FindGTest.html

However, that function would not allow the use of a driver
executable, since it would force the `gtest_filter` flag to
appear right after the executable name in the command, while
a driver executable would need the name of the test file
beforehand.

This commit introduces a custom version of GTEST_ADD_TESTS
where `extra_args` is called before the `gtest_filter` flag
to allow the use of an executable driver.

Note: as noted in the doc above[1], testing each gtest is
slow since they all necessite the startup of an executable.
The previous option of testing per file is therefore kept
but commented. A future focus of interest could be to
customize `add_test` to then run all gtests at once like
GoogleTest does by default.

Allows to create tests in iMSTK using google test and ctest.
Ctests are created by test files, and not by gtest functions.

Requirements:
- Requires a 'Testing' subdirectory with cpp files for each
  class to test.
- Google Test and Google Mock should be used to create unit
  tests, see the documentation below:
  https://github.com/google/googletest/blob/master/googletest/docs/Documentation.md
  https://github.com/google/googletest/blob/master/googlemock/docs/Documentation.md
- Test files should be constructed as described under\
  `imstk_add_test()` declaration

- Corrects wrongly named controller objects
in the Sandbox example

- Corrects wrong construtor call to the PBDObject

Refactor controllers

This MR aims to refactor the VirtualCouplingObject class into a SceneObjectController, as well as correct some style and architecture issues.

### STYLE: correct identation 97fc549f
Convert tabs to 4 spaces

### ENH: simplify TrackingController constructor fbc48bae
- Get rid of scaling in constructor (too many parameters, why choose scaling and not others? Use `setTranslationScaling` instead) 
- No more default `nullptr` value for `DeviceClient` in controller constructor

### ENH: Implement getMasterGeometry 85470771
Returns the master geometry. A geometry is qualified master by the direction of the geometry maps of the object. For example with a dynamic object, physic geometry will drive the changes to the colliding geometry, which will drive the changes to the visual geometry...

### ENH: Divide SceneObject & CollidingObject d8fee1f4 (fixes #84)
Colliding geometry is only in `CollidingObject, not `SceneObject`.  To do this, we also had to :
- Have `PbdObject` inherit `CollidingObject` *(in the future there should not be a distinct object class just for Pbd : there should just be dynamical objects that can use different models, like Pbd or FEM)*
- Remove useless checks when creating interactions: even two colliding objects (not dynamic, aka static) could be interacting if they are both controlled by devices

### STYLE: correct some includes and forward declarations 0340bde7

### ENH: remove interface for transforming geometry in RigidObject 7c272963
We are still wondering how to store/apply our geometries. Having yet another interface to only wrap the API to transform the geometry is not needed: we can directly call them on the geometry themselves for more transparency on what geometry is being updated. *This should be investigated later on when we will work with rigid body dynamics.*

### ENH: Refactor VirtualCouplingObject in a controller  (fixes #99)
- `SceneObjectController`: similar to cameraController, it subclasses trackingController to update the transformation of an object master geometry, instead of updating itself. 
- `SceneObject`: similar to camera, has an interface to easily setup a controller using a device client. 
- `CollidingObject`: stores the force vector that needs to be applied to the device.
- `SceneManager`: make the API calls from controller instead of object

### STYLE: Rename cameraController attribute to controller 9e199a30

See merge request !102

SceneObjectController: similar to cameraController, it
subclasses trackingController to update the transformation
of an object master geometry, instead of updating itself.

SceneObject: similar to camera, has an interface to easily
setup a controller using a device client.

CollidingObject: stores the force vector that is to be
applied to the device.

SceneManager: make the API calls from controller instead
of object

We are still wondering how to store/apply our geometries.
Having yet another interface to only wrap the API to
transform the geometry is not needed: we can directly
call them on the geometry themselves for more transparency
on what geometry is being updated.

This will be investigated later on when we will work with
rigib body dynamics.

Colliding geometry is only in CollidingObject.

To do this, we also had to :
- have PbdObject inherit CollidingObject (in the future
there should not be a distinct object class just for Pbd :
there should just be dynamical objects that can use
different models, like Pbd or FEM)
- remove useless checks when creating interactions: even
two colliding objects (not dynamic, aka static) could
be interacting if they are both controlled by devices

Returns master geometry, defined master in the
geometry maps of the objects. Physic geometry will
drive the changes to the colliding geometry, which
will drive the changes to the visual geometry

- Get rid of scaling in constructor (too many parameters,
why choose scaling and not others? Use setTranslationScaling
instead)

- No more default nullptr value for deviceClient in controller
constructor

convert tabs to 4 spaces

VRPN fixes (runtime, compilation, and external linkage)

1. VRPN would not be found in `FindVRPN.cmake` on Linux if `iMSTK_USE_OMNI` was set to ON.
2. A name issue in `iMSTKConfig.cmake.in` would prevent external projects to link against iMSTK
3. An offset was applied on VRPN devices on the client side while there already was a way to set up offsets in the controller interface

See merge request !101

Was triggered build errors on windows due to
std:to_string

FindVRPN: The order in which the libraries were
found was creating an compilation error during
linking on Linux, as well as windows when being
read from an external project.

iMSTKConfig.cmake.in: ${PROJECT_NAME} would not be
set to "iMSTK" from an external project.

External_VRPN: VRPN_BUILD_SERVERS:BOOL was defined
twice in imstk_add_external_project(VRPN)

The offset should only be defined at the
controller level

Also remove useless include in VRPNDeviceServer

Fix multiple omnis issue

* Fixes #71 

Co-authored by: @NickMilef <milefn@rpi.edu> 

1) DeviceClient : not a module anymore, only stores device info
and holds callbacks

2) VRPNDeviceClient : subclasses DeviceClient AND Module, to
conserve the ability to run multiple clients in parallel with
a VRPN server

3) HDAPIDeviceServer : new module that manages the HDAPIDevice
clients execution, which need to be made sequentially. Also helps
managing a unique hdScheduler.

4) HDAPIDeviceClient : lets the HDAPIDeviceServer handle the
hdScheduler. Also makes use of hdMakeCurrentDevice.

5) SimulationManager : refactor to run modules instead of
deviceservers or deviceclients

6) Sandbox : use new simulationManager API to add modules

See merge request !99

Co-authored by: Nicholas Milef <milefn@rpi.edu>

1) DeviceClient : not a module anymore, only stores device info
and holds callbacks

2) VRPNDeviceClient : subclasses DeviceClient AND Module, to
conserve the ability to run multiple clients in parallel with
a VRPN server

3) HDAPIDeviceServer : new module that manages the HDAPIDevice
clients execution, which need to be made sequentially. Also helps
managing a unique hdScheduler.

4) HDAPIDeviceClient : lets the HDAPIDeviceServer handle the
hdScheduler. Also makes use of hdMakeCurrentDevice.

5) SimulationManager : refactor to run modules instead of
deviceservers or deviceclients

6) Sandbox : use new simulationManager API to add modules

Allows to use iMSTK as an external library
for other projects.

Documentation here:
https://cmake.org/cmake/help/git-master/manual/cmake-packages.7.html#creating-packages

COMP: correct ftd2xx & libusb install rules

Fixes #66 for ftd2xx

Also correct mismatch between static and shared with libusb.

See merge request !96

Fixes #66

COMP: Update to specific git_tags for external projects

Using a git branch name for an external project would update the repository of that external project when building iMSTK even though it would not be tested.

By hardcoding a certain commit #, we can make sure we need to specifically update the external project git_tag to update the external project.

This commit updates to the newer version of VegaFEM which should resolve the remaining issues on the Dashboard for Windows: iMSTK/VegaFEM-CMake@d1ab0858
> `export(PACKAGE VegaFEM)` was resulting in Vega being registered in a CMake Package Registry :
> https://cmake.org/Wiki/CMake/Tutorials/Package_Registry
> 
> Because of this, an incorrect version of VEGA could be directly linked against when doing `find_package(VegaFEM)`.
> 
> This should only be done when creating a package for installation:
> https://cmake.org/cmake/help/git-master/manual/cmake-packages.7.html#creating-packages

See merge request !94

Integrate the following commit:
iMSTK/VegaFEM-CMake@7bc1bda6

Also remove useless iMSTK_EXTERNAL_PROJECTS_PATHS
variable in External/CMakeLists.txt

Using a git branch name for an external project would
update the repository of that external project when
building iMSTK even though it would not be tested.

By hardcoding a certain commit #, we can make sure we
need to specifically update the external project git_tag
to update the external project.

This commit updates to the newer version of VegaFEM which
should resolve some errors:

iMSTK/VegaFEM-CMake@d1ab0858

COMP: fix ftd2xx.lib copy at compile time

On some windows systems, the command `cmake -E copy`
within `copy_ftd2xx_static_command` renames the ftd2xx.lib
file as `lib\${BUILD_TYPE}` instead of copying it within
the directory of the same name. Because of this, the directory
can not be created in the future for other libraries, explaining
the high number of compilation errors (~50)

Placing a `\` at the end of the destination directory should fix
this issue.

See merge request !93

On some windows systems, the command `cmake -E copy`
within `copy_ftd2xx_static_command` renames the ftd2xx.lib
file as `lib\${BUILD_TYPE}` instead of copying it within
the directory of the same name. Because of this, the directory
can not be created in the future for other libraries, explaining
the high number of compilation errors (~50)

COMP: Fix COMP errors with LibNiFalcon

LibNifalcon should link against ftd2xx and not libusb1 on Windows. Add ftd2xx as an external project (binaries).

Works with the newest versions of VRPN and LibNiFalcon.

See merge request !91

ENH: add support for dashboard

http://my.cdash.org/index.php?project=iMSTK

See merge request !92

http://my.cdash.org/index.php?project=iMSTK