Kokkos: Containers: Commented out TRIBITS_ADD_LIBRARY in src/.

src/ doesn't currently have any source files, just header files.
Thus, there's no library to add, just header files to install.
TRIBITS_ADD_LIBRARY in that case may cause configure-time errors.
See comments in the changed src/CMakeLists.txt for a link to an
example.
Tpetra::Details::Directory: Changed interface so it no longer keeps Map.

This interface change will serve the port of Tpetra to use (new) Kokkos,
as explained below.

Details::Directory is the interface that implements Directory.
Directory keeps an RCP<const Map>; this is a circular reference, because
a Map also keeps an RCP<const Directory>.  We deal with this currently
using the "weak reference" capability of RCP.  However, once we port
Tpetra to use (new) Kokkos, Tpetra objects will become handles rather
than containers.  This will make RCP unnecessary.  However, it will
introduce the circular dependency issue, which Kokkos::View might not
necessarily be equipped to handle.  (I think it should be OK, since the
handles themselves are not reference counted; only their Views are.
However, I don't want to introduce potential problems.)

This commit moves Tpetra away from depending on circular references, by
starting with Details::Directory.  Directory itself is an implementation
detail of Tpetra, and therefore is also subject to interface changes at
will.  We will change Directory's interface next.
Tpetra::Directory: Changed interface so it no longer keeps Map.

This interface change completes what I began in my last commit.  It will
serve the port of Tpetra to use (new) Kokkos, as explained below.

Directory used to keep an RCP<const Map> of the Map that created it.
This was a circular reference, because a Map also kept an RCP<const
Directory>.  Map dealt with this circular reference by passing a
"nonowning RCP" (a weak reference) of itself to the Directory, on
creation of the latter.  The solution was ugly but functional.  I say
"ugly" because the only reason for Directory to keep a reference to its
Map was convenience.  Directory is an implementation detail of Map, so
it is easy for the owning Map to ensure that Directory's methods only
ever get passed the same Map each time.  Thus, it's trivial to change
Directory so that all its methods just take a const Map&, which is its
owning Map.

Once we port Tpetra to use (new) Kokkos, Tpetra objects will become
handles rather than containers.  This will make RCP unnecessary.
However, Kokkos::View might not necessarily be equipped to handle the
circular dependency issue.  (I think it should be OK, since the handles
themselves are not reference counted; only their Views are.  However, I
don't want to introduce potential problems.)

This commit moves Tpetra away from depending on circular references, by
removing the circular reference from Directory.  This introduces a
backwards-incompatible interface change to Directory.  However,
Directory is an implementation detail of Tpetra, and therefore is also
subject to interface changes at will.
Xpetra: fixed improper pragma
Tpetra: Directory: Fixed clone() to take const Map&, not RCP<const Map>.

This makes clone() consistent with the other changes to Directory's
interface in my previous two commits.
Xpetra: fixed Cloner test

It was using incorrect #ifdef for Epetra run
Bug fix given by Andrey Prokopenko.
Fixes memory problem in MueLu tests
Removed comments that were wrong
Minor change; not needed but perhaps cleaner to look at.
Panzer: Removed the local id from being stored on the mesh

Also updated the local id computation to include the neighbor elements.
Panzer: Modifying how neighbors elements are computed

Using the selector mechansim instead of a manual search. Also
add a STK_Interface::getNeighborElement method that allows
restriction to a specified element block.
Panzer: Incorporating neighboring (in one ring) elements into STK connection manager

This simply updates the connection manager interface so that it can
be used for ghosted elements. Its not the case that it must be used
in this way (for instance, ghosted elements are not required)
Panzer: Handling case where Ordinal64 is an int

This prevents linking of multiple "int" based objects, and will
hopefully help clean up the dashboard
Panzer: Allowing more flexibility in the evaluated field name for DOF_PointValues

You can now use the field name or the field name combined with the integration points.
Panzer: Adding method for evaluation of reference coordinates
MueLu: set lib in Level class as soon as Hierarchy creates a new level.

The lib member in the Level is set in the Hierarchy::Setup call. That should
be fine, but someone could create a Level using the Hierarchy without calling
Setup. When using the Level data strange things then occur (e.g. in context of
Level smoothers).
MueLu: initialize internal lib_ variable

Initialize internal lib_ variable with Xpetra::UseTpetra as default value.
Add additional check in CheckLevel routine whether lib_ has been set properly.
lib_ was not initialized before such that one could notice some strange problems
when creating TrilinosSmoother or DirectSolver objects.
MueLu: add a new example/tutorial

It uses Epetra only and generates a 2D Laplace example using Galeri.
MueLu: update tutorial2
MueLu: update tutorial

add files for hands-on session.