Modernize and modularize cmake build system for more robust usage

[wadehunk]

I re-factored the cmake build system to be more consistent with modern cmake conventions and best practices. I think this also simplifies and makes the overall build more maintainable. There was a previous PR that attempted to do this a few years ago, but looked like it got bogged down with too many changes. This implementation is a bit more direct although I ran into some pre-existing issues will DLL linkage consistency that required tweaking the DLL import/export macro implementation.

A quick summary of the changes:

• Utilized hierarchical CMakeLists.txt to manage files within each directory
• Library targets are created at the top-level with default library type, this allows the user to define whether a STATIC or SHARED library is created with a build option (-DBUILD_SHARED_LIBS=ON)
• Sources are added to library targets explicitly within each directory, avoid using GLOB operations as that is not recommended for managing build dependencies
• Dynamically generate header for specifying dll exports/imports
• Compilation of example sender/receiver applications is now specified with a CMake build option (-DBUILD_EXAMPLES=ON)
• SDL2 dependency options and targets are managed by FindSDL2*.cmake scripts now, which are modified versions of the Kitware FindSDL.cmake scripts
• More consistently utilized the GNUInstallDirs variables for file/target installation

Things that did NOT change:

• Exported targets/library names (OpenDIS6, OpenDIS7)
• C++ source code (Other than export macro in headers)
• Include paths
• Required minimum CMake version (3.2)
• Package targets

This should keep any impact to users of OpenDIS to a minimum if at all.

Tested locally on RedHat 8/9 (GCC) and Windows 10 (MSVC 2019)

[wadehunk]

@leif81 Had a false start on getting this submitted, but would love to get this merged. Looking to follow-up with re-integration of unit test suite and potentially Conan package support.

[leif81]

Thank-you @wadehunk ! It'll likely be next week when I am able to take a close look.

[leif81]

@wadehunk will this make #44 redundant?

[leif81]

@wadehunk took a first look and it looks good to me. I'm by no means a cmake expert though.

@rodneyp290 you may be interested in taking a look at this too. Any comments are appreciated.

[wadehunk]

@wadehunk will this make #44 redundant?

@leif81 I believe so. Primary difference is I didn’t try to reorganize any folders or add a dis7 example. Figured if that was needed it could be a follow up PR.

[rodneyp290]

Hey, long time no speak, I had a brief look. TBH, I've not that well verse in modern CMAKE - I've been meaning to learn properly it since #44 was made. But in general looks good, builds on my Linux System, and I see that it build on Windows through AppVeyor okay.

Nice work @wadehunk ! :+1: