Add shared library option

[dannys4]

Sorry for all of this unsolicited code, but I'm working with MrHyDE and would really like the ability to tap into is as a library and use it with external UQ tooling that I work on. Some reasons:

• While one could make all of the tooling internal to MrHyDE, that takes a lot of setup for each individual library.
• I could theoretically use File IO for a lot of this stuff (e.g. create an input.yaml and change it using Python/Julia/etc every time I want to change one particular parameter of the model), that's massively wasteful. In particular, that would require MrHyDE to construct and load a mesh at every iteration. If I'm running MCMC or something on a simpler PDE, the meshing could easily compare with (if not dominate) the cost of solving the actual problem.
• This would allow a much easier linking to a higher level language (e.g. Python/Julia)

This PR is more-or-less a fully-functional proof of concept, as any external library would need pretty detailed knowledge of the workings of MrHyDE. The idea is that, if this is merged, I'd go back in and instrument some kind of externalInterface.hpp or something, which would basically emulate the functionality in driver.cpp but wrap a bunch of the managers in a big object and allow you to change the object in "easier" ways. In particular, at least to get started, it would have:

• a function to set parameter values
• a function to run the solve
• a function to retrieve results from the analysis/postprocess (e.g. sensor data, adjoints, etc)

At least at first, I wouldn't bother interfacing with the UQ/optimization managers, because that would be a little too onerous. While I may be myopic, this would cover 80-90% of any use-cases for the library: allow external tools to access results to run custom postprocessing that would be out-of-scope for MrHyDE.

Notes on the PR:

• This does not affect the mrhyde executable in any way (to my knowledge)
• Adds an option MrHyDE_BUILD_SHARED_LIBS, which turns on/off the building of the shared library
• Adds cmake packaging so that an external library can just use find_package(MrHyDE REQUIRED) and target_link_libraries(<target_name> MrHyDE::mrhyde_lib) with, e.g., cmake -DMrHyDE_ROOT=<path_to_install_prefix>
• Most changes come from modifying pathing to be relative (instead of relying on include statements within the configuration). This is necessary for external linkage.
• Since this is just a proof-of-concept, the shared library won't work with all configurations of MrHyDE (hence the ability to turn it off), but it works with the default configuration.
• Unfortunately, it basically builds the same object files twice (once for the mrhyde binary, and once for the library). I'm not sure if there's a good way to consolidate those. Advice is appreciated

I'm open to any thoughts/advice/changes!