There is a generic ActionWithVirtualAtom class which can be used
as the base for Actions able to add new virtual atoms to the
system. Virtual atoms are stored in Atoms, can be referred to using
the label of the generating action. Automatically, they are
assigned an AtomNumber which exceed the real atom numbers
(e.g. if you have 108 real atoms, virtual atoms will have
indexes 108,109,...). They are automatically understood by
the parser provided one uses the parseAtomList() function.
Each instance of this class only generate a single virtual atom.
The nice thing is that, since lists of atoms can be dynamically changed
(e.g. by neighbor lists), dependencies are handled properly
and a virtual atom is only computed of the steps on which it is needed.

I also implemented a practical case, which is center-of-mass
(GenericCOM).

* Eliminated a possible tricky method to modify atom by relative index
* Eliminated duplicates in requested atom list

I also added a operators to AtomNumber, so it can be sorted with STL
algorithms

Tools to construct an AtomNumber given the serial or the index

Tired of typing "LABEL=", I added the possibility of specifying it as
a first word in the input line followed by ":". E.g.:
DISTANCE LABEL=d ATOMS=2,3
can be equivalently written as
d: DISTANCE ATOMS=2,3
saving 5 characters and putting the label in a more visible place

To get the real size occupied by the grid use getRealSize().

Should we have some inline function?

Nothing is stored in memory (as it was in plumed1).

Fix map between a monodimensional index and a pair of indexes in the case of all pairs from a single list

Basically plumed was crashing if NOT using ENERGY

I moved around stuff related to the total energy, in such a way that
energy CV is less different from the others. I also clarified the
main flux in PlumedMain with several comments

This is the equivalent of the old ALIGN_ATOMS directive.
It is more flexible in that it admits multiple lists of linked
atoms and can be applied multiple times.

I also added a GenericDumpAtoms class to write down a .xyz of
the stored (modified) positions, just to debug WholeMolecules.
We may extend it to other formats (e.g. .pdb or .gro).

(see manual)

Pbc are now stored in ActionAtomistic only, and not in Atoms.
This is more consistent: equivalently to atom positions,
Pbc are local to the Action.

Now all operations to retrieve atoms and to apply forces
are done by the ActionAtomistic class. This implies transfering
a bit of the complexity in Atoms to ActionAtomistic, which
is good. Also, it forces to follow a simpler scheme,
where each ActionAtomistic is requiring a single list
of atoms.

The advantage is that atoms are retrieved in usual Action
order (input file), so that it is easier to follow what the
code is doing. This also opens the way to Actions that
can modify the stored atomic positions for subsequent
Actions.

makefile.dep generation can now be done in parallel with make -j

multiply matrices by vectors, diagonalize (symmetric) matrices,
invert (symmetric and non-symmetric) matrices, calculate the determinant of
(symmetric) matrices and do cholesky decomposition.  Output is currently
only possible to the log.  Let me know if anyone needs anything else.

I think.

Otherwise it is not possible to apply restraints on it

It can be switched off (for testing) with SERIAL.
I added it so that there is an example of how to access to MPI
routines from Action.

Of course, we should also parallelize NeighborList search.

* a compiler warning
* neighbor list pointer was not deallocated

I also changed a bit the parser in ColvarCoordination so as to allow
default values

Nasty bug there. Actual requests of lists of atoms were forwarded to Atoms
object *during* dependence preparation, so that any change made immediately
after that was not taken into account. I temporarily solved this by
re-preparing dependencies again after calls to prepare(), but probably the
workflow has to be adjusted to be more robust.