Now that libplumedKerneldylib does not depend anymore on libplumed.dylib
it is possible to use two-level namespace on osx.

This change has two implications:
- the shared library used to resolve symbols during linking is recorded
  and used at runtime.
- all symbols should be available at link time

A side effect of this is that while compiling dylibs for the LOAD
action we should link them to the libplumedKernel as well.
For consistency I do the same on Linux, though it is not necessary in principle.

see 7a72bc37

Using completion the config.sh script is called during compilation.
This fix avoids problems when cltools is compiled before config

faster implementation, calls scripts once

Slow implementation, calls scripts everytime

with 315e6746

Fixed partial_tempering with gromacs 5 convention. Old behavior can be
forced with --gromacs4 option.

Can be retrieved with

plumed config mpiexec

Before this fix, atomtypes with 6 columns
were not working.

There was an issue when using
plumed vim2html --pdf --crop
on a plumed.dat file that is in a different directory.

(fixed by @a-cesari)

I implemented a shell-only tool "plumed config"

This tool can be used to probe the src/config/config.txt
configuration file.

So far it can be used e.g. as
plumed config has mpi
to enquire for an enabled feature.

It has some advantage wrt the --has-xxx options:

1. It is based on file src/config/config.txt,
which parses configure.ac and header files to find possible -D
and Makefile.conf to find activated -D.
This means that it is not necessary to manually
edit the src/config/Config.h and src/core/CLToolsMain.cpp
file to add new defines

2. it is shell only, thus works in cross compiled environment

(courtesy of Andrea Cesari)

- Implementation of short help (with :PHelp)
- Updated doc
- Autocompletion now knows if label was already provided at the beginning
  of the line and does not suggest it anymore in case
- Compilation of the vim plugin is more similar to compilation
  of the user doc
- Compilation of the vim plugin is made when doing "make install"
  from root dir.

allows syntax to be checked

Now plumed should work if built on a directory which has a space in the path.
Notice that install directory should still not contain spaces.
This is because of some difficulties in making the
src/lib/Makefile rules compatible with names with spaces.

Addresses #157

(cherry picked from commit 2ccba594)

    Backported changes from master to fix "plumed mklib"

    There was a problem with Makefile.conf as produced with ./configure
    if used in v2.0. This fix allows to use new Makefile.conf with old
    (2.0) plumed.

    This should fix the problem with rt15 mentioned by Gareth in
    the discussion of #76

Conflicts:
	src/config/Makefile

Target shared library is deleted before attempting its creation.
In this manner, if an error arises during compilation, the
library will not be there.

It is important to have LOAD FILE=xxx.cpp working properly.
E.g. if there is an error during compilation, a possibly existing
library is deleted.

There was an error in dihedral scaling (they were scaled with
sqrt(lambda) also if both terminal atoms were in the hot region)

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

I am experimenting with this. See comments in the
script file.

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.