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)

Also merge Utility within Core.

- Remove PThreads on Linux
- Correct CMake output directories in case of single
configuration type (not MSVC)

Corrects bug on Windows

All projects output directories are now common in
the top level. This commit takes care of the
CMAKE_CONFIGURATION_TYPES for Visual Studio.

With this commit the Find_XXX.cmake files do not need
HINTS anymore since all targets are built in a same
directory known to CMAKE_LIBRARY_PATH, and all headers
directories are referenced in CMAKE_INCLUDE_PATH.