The main bottleneck with real-time VTK rendering so far
appeared to be the normals computation. This commit addresses
that issue by making use of the latest normals computation
filter in VTK: vtkTriangleMeshPointNormals.

While this filter is much (5 to 16 times) faster than
vtkPolyDataNormals, it does not check for consistency in the
cell orientations that could cause inverted normals, which
is why the vtkPolyDataNormals is called once in the surfacemesh
renderdelegate to retrieve consistent cells for the input mesh.

See VTK merge request for more information :
vtk/vtk!2271

PS: That MR requires the latest commits from VTK master, which
does not include work made on texture wrap mode nor on multi
texture attributes yet:
- vtk@62a7ecd8
- vtk@ae373026

define "StdVectorOfxxx" for all eigen matrix structures
used in iMSTK within std::vector.

See http://eigen.tuxfamily.org/dox-devel/group__TopicStlContainers.html

Requires to update SCCD to commit 645508940
which also updates its vec3 structure.

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.

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

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)

Fixes #66

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

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)

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

Using CMAKE_CXX_STANDARD and THREADS_PREFER_PTHREAD_FLAG

After rebasing on dynamics-sprint, the following
errors appeared:
- change from VecNf to VectorF
- wrongfully placed 'virtual' in MassSpringForceModel
- wrongfully placed '#endif' in MassSpringForceModel
- missing include in NonLinearSolver
- error in constructor in NonLinearSystem
- error in Eigen include in TimeIntegrator
- error in VTK remote address in External_VTK.cmake

Also build VRPN servers target to build
vrpn_phantom, and correct call to vrpn_Phantom
in VRPNDeviceServer

Removed in SCCD external project since not
supported on Mac.

Still need to connect callbacks to retrieve collision data.

PR: https://github.com/libnifalcon/libnifalcon/pull/46

Based on improve-cmake that was merged:
https://github.com/libnifalcon/libnifalcon/pull/43

LibNiFalcon is an external project dependency on every system.

On Mac and Linux, libusb1 would be found
with other names.

Needed for VRPN. Use fork made for cmake improvements
and plan for a pull request:
https://github.com/agirault/libnifalcon/tree/improve-cmake

Could not link against hidapi on windows (setupapi)

Not sure about the need for libusb1 on windows.

Comments added to FindVRPN to analyze what is happening.

1) Only output to CMAKE_XXX_OUTPUT_DIRECTORY without
worrying about CMAKE_CONFIGURATION_TYPES

2) Use CMAKE_CFG_INTDIR to correctly set CMAKE_LIBRARY_PATH
after the change 1)

3) Use mark_as_superbuild() to pass variables to external
projects and innerbuild. (${PROJECT_NAME}_EP_ARGS)

4) Remove unecessary steps in eigen project (only includes, no lib)

5) Use standard imstkAddExternalProject for Uncrustify (not tested)