Rework null space code for ML/MueLu.

1. The rotational part of the rigid body modes calculated by ml_rbm.c and copied
into Piro/Albany_NullSpaceUtils assumes the centroid of (0,0,0) is adequate. At
the very least, this means the problem is not invariant to translation of the
mesh. For a mesh constructed far from the origin, this assumption could also
degrade the quality of the near null space. Hence I've added code to calculate
the centroid.

2. I've redesigned RigidBodyModes to unify the ML and MueLu code paths, both in
that class and also in the STK/FMDBDiscretization classes.

3. Temporary. On tet meshes, MueLu often fails when ML does not. I have
confirmed this is true for both the Cubit-decomp-STKDiscretization work flow and
code path and the Simmetrix-split-FMDBDiscretization ones. In the course of
debugging the problem, I discovered that the MueLu problem is not triggered if I
use just the translation part of the RBM null space; moreover, the convergence
speed is adequate in the problems for which I have tried this hack. Hence I'm
(probably temporarily, until we fully resolve the MueLu issue) adding a
ParameterList parameter to FMDBDiscretization that lets the user request that
just the translation part of the near null space be set. For now I'm not adding
the parameter to STKDiscretization because all of this work is for the
SCOREC-related projects.

I'm bringing this code into the Albany repo and namespace for at least two
reasons. First, I've changed the interface substantially; such changes to the
interface in the Piro package would break other branches, in particular the
Epetra branch. Second, for our external collaborators, the delay between Albany
and public Trilinos repo updates can be a problem. In this case, this work is
motivated by our collaboration with RPI, and I don't want to wait for the public
Trilinos repo to update. Even if I eventually move the new RigidBodyModes class
back into Piro, I'd like to stage it in the Albany repo for now.