Mcpl

* Work again with latest numpy by removing usage of deprecated numpy.float
and numpy.int aliases (Thanks Milan Klausz and Jose Robledo, see also
github issue 72).

* Fixed mcplexample_pyread so it is able to work without the user setting
PYTHONPATH (this is still not very robust as it for now assumes that the
user did not modify the default installation location).
* Attempt to improve MCPL_ENABLE_ZLIB=FETCH mode by applying correct
private compilation definitions.

* Updated all MCPL CMake options to have named prefixed with MCPL_ and use
a more consistent naming scheme (mctools/mcpl67). For example
BUILD_EXAMPLES is now instead MCPL_ENABLE_EXAMPLES. See the file
cmake/modules/mcpl_options.cmake for details.
* The default behaviour was until now to try to locate ZLIB and let the
configuration fail if not succesful, unless the old option
BUILD_WITHZLIB was explicitly set to OFF. The new option
MCPL_ENABLE_ZLIB is more flexible and supports one of several values:
IFAVAILABLE, FETCH, USEPREINSTALLED, ALWAYS, OFF, or NEVER. The default
value of IFAVAILABLE will try to locate ZLIB, but will simply disable
ZLIB support if unsuccesful. The aliased options OFF and NEVER are
obviously simply disabling ZLIB support irrespective of presence on the
system. The option ALWAYS will attempt to find ZLIB on the system, and
if it fails it will instead fetch the zlib sources from the official
zlib location at github, and build the appropriate capabilities right
into the MCPL binaries. The option, USEPREINSTALLED is actually like the
old default behaviour: look for ZLIB on the system and fail if it it is
not available. Finally, the option FETCH will always fetch sources
online, ignoring any ZLIB already present on the system.
* Add (hidden) option MCPL_ENABLE_CPACK. If set, a few CPACK-related
variables will be set and an "include(CPack)" statement is triggered
just after the "project(..)" statement (mctools/mcpl68).
* We now newer fiddle with CMAKE_BUILD_TYPE if a multi-cfg generator is
detected.
* Add (hidden) option MCPL_DISABLE_CXX.. If set, C++ support is not
requested from CMake, potentially removing an unnecessary
dependency. This option should obviously not be used with
MCPL_ENABLE_GEANT4=ON.

* Allow MCPL_PYPATH and MCPL_CMAKEDIR to be modified by users.
* Avoid CMake warnings when setting MCPL_NOTOUCH_CMAKE_BUILD_TYPE.
* Rename CMake target "common" to "mcpl_common" to avoid clashes when
project is build as a subproject (mctools/mcpl65).

* Add mcpl-config script which can be queried for details about a given
installation, or even used to setup the user environment by typing
"eval $(./path/to/mcpl/installation/bin/mcpl-config --setup)" in a
shell.
* Modify location of CMake config files provided by an MCPL installation,
to hopefully make it easier for downstream projects to locate an existing
MCPL installation (more details on github issue 58).
* Modify manner in which Geant4 bindings must be activated in downstream
CMake code. Previously they were enabled via a dedicated
"find_package(G4MCPL)" call, but now they are instead provided as an
optional COMPONENT when requesting the MCPL package:
"find_package(MCPL COMPONENTS GEANT4BINDINGS )". The Geant4 bindings
will not be enabled unless this component is explicitly requested.

* Major update to CMake code, which first and foremost makes it possible
for downstream CMake-based projects to use find_package( MCPL ) and
through that get access to variables MCPL-related variables and build
targets (i.e. the MCPL::mcpl target for projects needing to include
mcpl.h and link against the compiled mcpl library). This is done in
response to a request from Paul Romano (github issue 58).
* The new minimum CMake version required is 3.10. Users having issues with
this or other of the new CMake-related changes are recommended to stick
with release 1.3.2 for now (and open issues in the tracker at
https://github.com/mctools/mcpl/issues in case the problem is suspected
to be on the MCPL side of things).
* Now using the GNUInstallDirs module to determine locations of files in
the installation. This is considered best practice, and also provides
a fine-grained control to users who might need it.
* Changed the default to NOT build and install the examples and Geant4
hooks. These can still be enabled explicitly as needed of course with
-DBUILD_EXAMPLES=ON and/or -DBUILD_WITHG4=ON.
* Now attempting to use RPATH's in mcpltool and other installed examples
(to potentially help users avoid messing with LD_LIBRARY_PATH to run
commands such as mcpltool). To prevent this, set -DMODIFY_RPATH=OFF.
* All shebangs (!/usr/bin/env python3) in Python scripts now refer to
python3 rather than merely python (github issue 55). Users having
issues with this due to being on very old platforms are recommended to
stick with release 1.3.2 for now (and open issues in the tracker at
https://github.com/mctools/mcpl/issues in case the problem is suspected
to not be related to having an ancient platform).
* Replaced a strncpy call in mcpl.c with memcpy, to avoid a compilation
warning under some conditions. Beyond fixing a potential compilation
warning, there should be no changes to functionality.