The rewrite uses more cmake build-in automatisms and build-in generates
variables to allow better generic reuse.
* cmake  files are installed to
``` <install_prefix>/lib/cmake/nlohmann_json/ ``` for best support on
most systems
* include path is set to ``` include ```  for usage as ``` #include
<nlohmann/json.hpp> ```

This avoids potential conflicts with other libraries when the library is
built from source and included in a bigger cmake build.

- Add prefix header
  - Include catch.hpp
  - Include json.hpp
    - Replace private with public for all json_unit files
- Move `unit.cpp` to an object library
- cotire issue: strip whitespace from CMAKE_INCLUDE_SYSTEM_FLAG_CXX

Instead of copying the test executable and the JSON files used by
the tests at install time, define CMake/CTest tests for running
the json_unit executable from any build directory with the project's
source directory as its working directory.

- call enable_testing in the main lists file to allow the definition
of tests
- remove install commands from the test directory's lists file
- define two tests
  - json_unit_default for running the default tests by executing
json_unit without any arguments
  - json_unit_all for running all the tests by executing json_unit
with the "*" argument
- update the AppVeyor configuration file to use the new testing method

This introduces a clear separation between test data and test
binaries. Test data is moved into test/data, and the test binaries
move into test/src. A new CMake script specific to building the
tests is introduced in /test to slightly clean up the toplevel
one.

As well as tidying things up, this makes the next step trivial...

There exist lots of json libraries, and project/target names must
be globally unique. If someone integrated with this library in a
particularly stupid way, using a generic name like "json" might
cause a problem.

I'm not sure that using a variable for target names really helps
with clarity. Unlike paths, target names aren't really something
you change. In a sense, targets are themselves a sort of variable,
so having a variable to name a variable seems just a bit gnarly.

Generate the config files of the package in CMAKE_CURRENT_BINARY_DIR
instead of CMAKE_BINARY_DIR because the later will refer to the main
project's binary directory if the library is included in the project
using the add_subdirectory command.

- define the project's version in the cmake listfile
- create a config and config version file for the cmake package
- install the json.hpp file and the package's targets, config and
config version files

Define the library as an interface imported library so other targets
can use the library as a dependency and use the interface properties
of the library.

- additionally, switch off optimization flags to maybe allow build to
complete on AppVeyor