Epetra: CrsMatrix: Fixed some (not all) shadowing warnings.
Split Tpetra into subpackages; moved Kokkos{Classic,TSQR} to Tpetra.

WARNING: This affects all downstream packages of Kokkos and Tpetra.
It may affect Domi and Phalanx in particular.  See details below.

WARNING: The configuration passes, but Tpetra build with ETI (explicit
template instantiation) enabled does NOT currently work.

I moved the KokkosClassic and KokkosTSQR subpackages out of Kokkos and
into Tpetra.  Tpetra now contains three subpackages:

  - Classic (the former KokkosClassic subpackage of Kokkos)
  - TSQR (the former KokkosTSQR subpackage of Kokkos)
  - Core (the previous entire contents of Tpetra)

I changed the package dependencies of Domi and Phalanx to reflect this
change; they now depend on "TpetraClassic" instead of "KokkosClassic".
This shouldn't affect Domi much because it already has an optional
dependency on Tpetra.  It might affect Phalanx but I don't have a good
way to test this, so please feel free to report if it causes problems.

NOTE: I have only tested configuration, with MPI, using the following
check-in test script line:

  --enable-packages=KokkosCore,KokkosCompat,KokkosContainers,KokkosLinAlg,KokkosAlgorithms,KokkosMpiComm,Tpetra \
  --no-enable-fwd-packages --send-email-to="" --default-builds="" \
  --extra-builds=MPI_DEBUG_KOKKOS_REFACTOR --allow-no-pull --configure

The configuration passes.
Kokkos,Tpetra: Fixed build (?) following subpackage move.

This relates to my previous commit, in which I moved the KokkosClassic
and KokkosTSQR subpackages of Kokkos into Tpetra.  In that commit, I
was able to get the CMake configuration step to pass.  In _this_
commit, I was able to get the build to pass -- but ONLY for Kokkos and
Tpetra.  I have not yet tested downstream packages.

NOTE: Tpetra ETI (explicit template instantiation) is different than
before.  ONLY the TpetraCore subpackage of Tpetra has ETI support.
That may change in the future, but I found that a little bit less
risky than turning on ETI for subpackages that don't support it (like
Classic or TSQR).  Your build scripts might need to change a little
bit, though you generally shouldn't be enabling ETI _just_ for Tpetra.
Just turn on ETI for all of Trilinos -- it works for me.
PyTrilinos,Stokhos,Zoltan2: Removed explicit dep on Tpetra_config.h.

Tpetra_config.h doesn't exist anymore.  The equivalent new file is
TpetraCore_config.h, but you should really just include
Tpetra_ConfigDefs.hpp.
Kokkos: Moved FENL example from KokkosExample to KokkosLinAlg.

The FENL example depends on KokkosCore, KokkosContainers, and
KokkosLinAlg.  No other examples in the KokkosExample subpackage
depend on KokkosLinAlg.  Since we want to move KokkosLinAlg out of
Kokkos and into Tpetra, as a first step, I have moved the FENL example
out of KokkosExample and into KokkosLinAlg.

I also changed KokkosExample's dependencies so that it no longer
depends on KokkosLinAlg.
KokkosExample: Added README to identify examples.

The README was hastily written and I don't really know what all the
examples actually do (what's the difference between feint and fixture,
for example?).  Please revise this.
Moved KokkosLinAlg subpackage from Kokkos into Tpetra as TpetraKernels.

I moved the KokkosLinAlg subpackage of Kokkos into Tpetra, and renamed
it "TpetraKernels".  This move will facilitate moving Kokkos from the
Trilinos repository into its own Github repository.  I renamed it from
"LinAlg" because all of Tpetra implements "linear algebra."  The name
"Kernels" better suggests the contents: single-MPI-process,
thread-parallel computational kernels.

I also fixed downstream packages that depended on KokkosLinAlg.  This
includes both the package name (KokkosLinAlg -> TpetraKernels) and
various library names.

This commit mainly affects Kokkos and Tpetra.  I also had to make
minor changes to Isorropia, ShyLu, Stokhos, TrilinosCouplings, and
Xpetra.  In particular, Xpetra's "FakeKokkos" (KokkosClassic
replacement headers for when building with Tpetra disabled) caused
some bizarre build errors until I finally figured out that Xpetra was
using "Xpetra_ENABLE_Kokkos" to key on whether to use FakeKokkos'
headers.  This manifested as Tpetra files not getting the contents of
TpetraClassic files (like Kokkos_ConfigDefs.hpp), but only when
building in Xpetra.  I fixed this by making Xpetra key on
Xpetra_ENABLE_Tpetra, since the former KokkosClassic now lives in
Tpetra.

NOTE: The Kokkos refactor version of MueLu does not currently build
with ETI enabled, because of some missing explicit instantiations.
Here is the error message I get:

Linking CXX executable MueLu_Challenge_XML.exe
../../../src/libmuelu.so.11.13: undefined reference to `Ifpack2::AdditiveSchwarz<Tpetra::RowMatrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> >, Ifpack2::Preconditioner<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> > >::AdditiveSchwarz(Teuchos::RCP<Tpetra::RowMatrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> > const> const&, int)'
../../../src/libmuelu.so.11.13: undefined reference to `Ifpack2::Details::OneLevelFactory<Tpetra::RowMatrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> > >::create(std::string const&, Teuchos::RCP<Tpetra::RowMatrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> > const> const&) const'
../../../src/libmuelu.so.11.13: undefined reference to `Ifpack2::Chebyshev<Tpetra::RowMatrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> > >::getLambdaMaxForApply() const'
../../../src/libmuelu.so.11.13: undefined reference to `Ifpack2::Hiptmair<Tpetra::CrsMatrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> > >::Hiptmair(Teuchos::RCP<Tpetra::RowMatrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> > const> const&, Teuchos::RCP<Tpetra::RowMatrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> > const> const&, Teuchos::RCP<Tpetra::RowMatrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> > const> const&)'
../../../src/libmuelu.so.11.13: undefined reference to `Ifpack2::Krylov<Tpetra::RowMatrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> > >::Krylov(Teuchos::RCP<Tpetra::RowMatrix<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP> > const> const&)'
collect2: error: ld returned 1 exit status

Note that KokkosDeviceWrapperNode<Kokkos::OpenMP> is NOT the default
Node type in this build; the default Node type is
KokkosDeviceWrapperNode<Kokkos::Serial>.  As far as I can tell,
Ifpack2 only does ETI for the default Node type.  It could be that
MueLu is explicitly requesting ETI for a NON-default Node type, or it
could be that I messed up somewhere with the macros.  I'll have to
work a little bit harder at this, but I think it's OK to finish the
subpackage migration process first.
Moved Compat and MpiComm subpackages from Kokkos into Teuchos.

The former Compat and MpiComm subpackages of Kokkos, are now the
KokkosCompat resp. KokkosComm subpackages of Teuchos.  This move will
facilitate migration of Kokkos out of Trilinos into its own Github
repository.

NOTE: I have not yet updated other Trilinos packages to reflect the
new subpackage names!  The point of this commit is to provide a
midpoint for bisection, in case subsequent commits don't work.
However, I _have_ reversed the order of Kokkos and Teuchos in
Trilinos' main package list (Trilinos/PackagesList.cmake).

NOTE: I'm not sure if I need to update teuchos/TPLsList.cmake.  The
point of that seems to be so that Teuchos can build as a stand-alone
project.  Introducing subpackages, even optional ones, that depend on
Kokkos might affect this capability.
Updated packages due to KokkosCompat and KokkosMpiComm rename.

This commit fixes Trilinos packages downstream of Kokkos and Teuchos,
after my previous commit that moved the Compat and MpiComm subpackages
out of Kokkos and into Teuchos (as KokkosCompat resp. KokkosComm).

I also took the opportunity to replace "KokkosClassic" with
"TpetraClassic" where sensible.  This relates to my earlier commit
which moved the KokkosClassic subpackage out of Kokkos into Tpetra (as
"TpetraClassic").  In particular, I fixed scripts for configuring
Trilinos for various Dashboard builds.  I also changed example shell
scripts for configuring Trilinos.
KokkosExample: Fixed DEPLIBS warning
TpetraClassic: Fixed broken CMakeLists.txt file
Tpetra::MultiVector: Fixed build warning (unused typedef)
Tpetra::MultiVector: Fixed build error due to subview change.

This commit only affects the Kokkos refactor version of Tpetra.
TpetraClassic: Fixed build error with ThrustGPUNode
TpetraTSQR: Disabled KokkosNodeTsqr test.

KokkosNodeTsqr does not work with the new Kokkos Node types.  I plan
to rewrite TSQR anyway to work with new Kokkos.  I will disable this
test for now and come back to it later.
MueLu: Fixing circular dependency issues
MueLu: Removing repeated include

Build/Test Cases Summary
Enabled Packages: MueLu
Enabled all Forward Packages
0) MPI_DEBUG => Skipped configure, build, test due to no enabled packages! => Does not affect push readiness! (-1.00 min)
1) SERIAL_RELEASE => Skipped configure, build, test due to no enabled packages! => Does not affect push readiness! (-1.00 min)
2) MPI_DEBUG_SS => passed: passed=249,notpassed=0 (40.95 min)
Other local commits for this build/test group: 1a1fd16
MueLu: use master list for default parameterlist syntax value
MueLu: minor fix in users guide
Tpetra::MultiVector: Fixed View init to use intended execution space.

This commit only affects the Kokkos refactor version of Tpetra.

In Tpetra, it's important to template Views (and DualViews) on the
intended execution space, not on a memory space.  This ensures that
Tpetra will use exactly the specified execution space(s) and no
others.

This matters because View (and DualView) initialization is a parallel
Kokkos kernel.  If the View is templated on an execution space, Kokkos
uses that execution space (and only that execution space) to
initialize the View.  This is what we want.  If the View is templated
on a _memory_ space, Kokkos will use the memory space's default
_execution_ space to initialize.  This is not necessarily what we
want.  For example, if building Trilinos with OpenMP enabled, the
default execution space for host memory is Kokkos::OpenMP, even if the
user-specified DeviceType in Tpetra is Kokkos::Serial.  (This shows up
as a thrown exception, complaining that OpenMP has not yet been
initialized.)