Added more ways to check if tools are installed. Now also
plumed --has-matheval
is allowed

I replaced all the "using namespace PLMD" statements with explicit
namespace PLMD{ …… }. This is more clear and simplify the syntax for
defining operators

Now the file containing the configuration options is a .cpp file.
This limits the effect of the change in the configuration to
a single object file and remove the need for BUILDAFTER variable
in Makefiles

All the source code have been moved into subdirectories of src/
Some of these subdirectories are treated in a special manner:
src/wrapper contains the wrappers for MD codes
src/main contains the main.cpp file
src/config contains files generated without compilation,
  just based on configuration info
src/lib is the place where executables and libraries are put
  at the end
src/cltools contains the command line tools
src/tools contains plumed tools (reusable classes)
src/basic contains PlumedMain, Action hierarchy and other basic stuff
src/multicolvar contains MultiColvar stuff
src/imd is the interactive MD (still not totally portable).

Notice that, to allow easy inclusion of .h files from other modules,
I link all the directories in src/ into module directory. In this
way it is possible e.g. to write #include "config/PlumedConfig.h"

See src/README and src/basic/Makefile to understand how inter-module
dependencies are set

It allows running plumed in a different environment from
where it was compiled (e.g. windows).

re-passed in to main of CLTools.  Also fixed some mistakes
in the developer documentation for Colvars and Functions

command line tools easy to document in the same manner as Actions are
easy to document

as suggested by Gareth

I added a PEOPLE file containing list of authors and a script
(src/header.sh) which applies the Licence to all the source files.

It can be applies multiple times (it automatically deletes the present header
and replace it with the new one). Thus, to change the header, edit header.sh
and execute it.

I think it is cleaner to just set it when using the system()
or popen() call

I modified the command line tools stuff so that it is now possible
to access it using the Plumed.h interface (i.e. cmd(...)). This
allows to call the command line tools directly from other languages,
and is more consistent with the way plumed library is accessed from
MD codes. Notice that now also a plumed-runtime executable
is produced, which looks for PLUMED_KERNEL variable at runtime
to choose the proper library to load. Since all the command line
tools are built inside the library, this just means that a
different plumed version is used (similar to runtime mode
for patching MD codes).

Moreover, I hard-coded the PLUMED_ROOT variable in the
PlumedConfig.h header file. In this manner, it is sufficient to
have plumed in the path.

plumed --no-mpi does not initialize MPI.

It could be useful to avoid MPI initialization when
running serially. However, on sp6@cineca, it seems that
startup spees is not sensitive to this parameter: the only
way to have an executable which immediately runs is to
compile it without MPI! Still I leave this option here.

Now there is a single "plumed" binary in /src
(plus a plumed-static binary, equivalent but statically bound),
which can be used to do patches, call the driver, etc.

Notice that I changed the generated sourceme.sh file
accordingly: now the "plumed" binary should be reachable.

I re-implemented all the features that were in the /tools/plumed
script. I also added a virtual method to the CLTools so that
they can specify a single-line description of what they do
(this is useful to generate the output of "plumed -h")

I added the communicator as an argument of main()
function in CLTool.h. This means that each tool
will be runnable with MPI. Notice that
the communicator defaults to MPI_COMM_WORLD,
which is the reasonable choice. Still I think it is
useful to allow passing the communicator if one wants
to run with MPI several tools in parallel.

I tried to do it in such a manner that everything fits
into the plumed library (but for a trivial "main"),
so that all the command line tools can indeed be called as if they
were routines.

I used a base class CLTool which can be inherited from, similarly
to the Action class. I also temporarily copied ActionRegister
stuff into a CLToolRegister which allows registering of tools
at startup. This allows for a very flexible extensibility: it
is sufficient to load runtime a library containing a CLTool and
it becomes available.