Fixing ignores to only ingore files in Trilinos dir (Trilinos #5970)

The way I had it, CPack was excluding all of these same files under VERA as
well.  This took out the VERA install hooks because it installs a file under
VERA/docs.

Build/Test Cases Summary
Enabled Packages: TrilinosFramework, TeuchosCore
0) MPI_DEBUG => passed: passed=161,notpassed=0 (3.28 min)
1) SERIAL_RELEASE => Test case SERIAL_RELEASE was not run! => Does not affect push readiness! (-1.00 min)
Added a little documentation.
Added add support for --dist-version-file with unit tests (VRI Kanban #3006)

I have added support for --dist-version-file and --dist-version-file2
arguments (see egdist --help for details).  I kept egdist a stand-alone python
script which just depends on standard Python 2.4. modules.  I added unit
testing suport for the basic functioning as well as the new features.  This is
very nice.  I had to add a symbolic link egdist.py so that I could include
egdist as a module for unit testing.  No big deal.  People could actually copy
egdist.py and use it as well if they would like.

Build/Test Cases Summary
Enabled Packages: TrilinosFramework
Disabled Packages: CTrilinos,ForTrilinos,PyTrilinos,Didasko,Mesquite,Phdmesh,Pliris,Claps
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=115,notpassed=0 (1.29 min)
1) SERIAL_RELEASE => Test case SERIAL_RELEASE was not run! => Does not affect push readiness! (-1.00 min)
Making git cmnd error message FATAL_ERROR in creation of <Project>RepoVersion.txt (Trilinos #5967)

This now produces error messages like:

fatal: Invalid gitfile format: .git
CMake Error at Trilinos/cmake/tribits/package_arch/TribitsGlobalMacros.cmake:843 (MESSAGE):
  ERROR, /projects/vera/common_tools/git-1.7.0.4/bin/git command returned
  128!=0 for extra repo /home/8vt/localhome/PROJECTS/VERA.base/VERA/Scale!
Call Stack (most recent call first):
  Trilinos/cmake/tribits/package_arch/TribitsGlobalMacros.cmake:924 (TRIBITS_GENERATE_SINGLE_REPO_VERSION_STRING)
  Trilinos/cmake/tribits/package_arch/TribitsGlobalMacros.cmake:951 (TRIBITS_GENERATE_REPO_VERSION_FILE_STRING)
  Trilinos/cmake/tribits/package_arch/TribitsGlobalMacros.cmake:994 (TRIBITS_GENERATE_REPO_VERSION_OUTPUT_AND_FILE)
  Trilinos/cmake/tribits/package_arch/TribitsProjectImpl.cmake:146 (TRIBITS_GENERATE_REPO_VERSION_OUTPUT_AND_FILE_AND_INSTALL)
  Trilinos/cmake/tribits/package_arch/TribitsProject.cmake:75 (TRIBITS_PROJECT_IMPL)
  CMakeLists.txt:50 (TRIBITS_PROJECT)

-- Configuring incomplete, errors occurred!

and then stops right away.

Otherwise, you have to wait for the whole configure to see that something
failed!

Build/Test Cases Summary
Enabled Packages: TrilinosFramework
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=115,notpassed=0 (1.42 min)
1) SERIAL_RELEASE => Test case SERIAL_RELEASE was not run! => Does not affect push readiness! (-1.00 min)
Removing debug print statement (VRI Kanban #3006)

Build/Test Cases Summary
Enabled Packages: TrilinosFramework
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=115,notpassed=0 (1.37 min)
1) SERIAL_RELEASE => Test case SERIAL_RELEASE was not run! => Does not affect push readiness! (-1.00 min)
Fixed typo in output found by Joel K. at WEC.
Adding install target for <Project>RepoVersion.txt from tarball source

When building a tarball, the <Project>RepoVersion.txt file gets put into the
tarball.  This new install hook looks for that file in the source tree and if
it finds it, installs it into the installation tree.

This is an important part of version tractability for releases.

I tested this manually and it worked as expected.
Allowing TriBITS projects to define the default for ${PROJECT_NAME}_ENABLE_CPACK_PACKAGING (Trilinos #5970)

With this change, TriBITS projects can now define the default value for
${PROJECT_NAME}_ENABLE_CPACK_PACKAGING as the variable
${PROJECT_NAME}_ENABLE_CPACK_PACKAGING_DEFAULT.  For Trilinos, this is set to
ON. For all other projects by default this is set to OFF.
Made subpackage tarball exclusion optional, fix ignores (Trilinos #5970)

There are a number of things I have done here to fix up the TriBITS support
for CPack packaging and the Trilinos-specific excludes:

* New varible ${PROJECT_NAME}_EXCLUDE_DISABLED_SUBPACKAGES_FROM_DISTRIBUTION
  (with project-specific default
  ${PROJECT_NAME}_EXCLUDE_DISABLED_SUBPACKAGES_FROM_DISTRIBUTION_DEFAULT)
  toggles between having disabled subpackages excluded from the tarball or
  not.  For Trilinos the default is FALSE according to the wishes of the
  Trilinos developers.

* Fixed Trilinos-specific excludes base dir.  I fixed the base directory so
  that it works both when Trilinos is the base TriBITS project and when it is
  just an extra repo in a larger TriBITS project.

* Added back exclude of *.pyc files with safe and correct file extension regex
  .*[.]pcy$. This now only applies to Trilinos!

* Added back package-specific exclude of *.m4 files using the safe and correct
  file extension .*[.]m4$.

* Move ignores of git repo files .git, .gitingore, and .egdist to TriBITS
  itself.  I think these files and dirs should universally be exclude from the
  git repo.
Moving to generalize (Trilinos #5970)
Breaking up packaging callback into repo and project versions, specialize soruce gen types (Trilinos #5970)

Now there are two callback files, one for the repo and one for the project.
The file CallbackDefineRepositoryPackaging.cmake get called always (if the
repo isincluded at all) and the file CallbackDefineProjectPackaging.cmake only
gets called if this is the base TriBITS project.  No more if statement looking
at the project name.

Added the cache variable ${PROJECT_NAME}_CPACK_SOURCE_GENERATOR to set
CPACK_SOURCE_GENERATOR and allow the project to define the default
${PROJECT_NAME}_CPACK_SOURCE_GENERATOR_DEFAULT.  You can't ask for any more
flexibility or specialization than this!
Merge remote branch 'origin/vera-release-rsicc-2013'
Defining CPACK_SOURCE_GENERATOR before its first use (Trilinos #5970)

In my last refactoring, I broke the code that copied the
<Project>RepoVersion.txt into the tarball.  This change fixes that.
Updated for new documentation template.

Build/Test Cases Summary
Enabled Packages: VERAIn
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=164,notpassed=0 (34.85 min)
1) SERIAL_RELEASE => passed: passed=120,notpassed=0 (23.80 min)
Other local commits for this build/test group: 244d771, db07fcb, 1674f86, 9a54cd1, c054263, 02a466c, 0d25458
Merge remote branch 'casl-dev/master'
NOX: fix for aa condition number monitoring.  All set to go now!

Build/Test Cases Summary
Enabled Packages: NOX
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=181,notpassed=0 (17.67 min)
1) SERIAL_RELEASE => passed: passed=181,notpassed=0 (3.24 min)
Disabling test Rythmos_ImplicitRK_UnitTest_MPI_1 from checkin-test pushes (Trilinos #5979)

The test Rythmos_ImplicitRK_UnitTest_MPI_1 had one failing unit test
Rythmos_ImplicitRKStepper_setDirk_UnitTest for this configuration and shows
valgrind errors in another clean checkout and build (see Trilinos #5979).
This failing tests is stopping my push so I am disabling it indefinitely.
Merge branch 'master' of software.sandia.gov:/space/git/Trilinos

Build/Test Cases Summary
Enabled Packages: TrilinosFramework
Disabled Packages: CTrilinos,ForTrilinos,PyTrilinos,Didasko,Mesquite,Phdmesh,Pliris,Claps
Enabled all Packages
0) MPI_DEBUG => passed: passed=1465,notpassed=0 (6.63 min)
1) SERIAL_RELEASE => passed: passed=1442,notpassed=0 (27.67 min)
Other local commits for this build/test group: 9fb7799, cd445de, a9ce78e, 244d771, db07fcb, 1674f86, 9a54cd1, c054263, 02a466c, 0d25458, 00fd1d2, 0f4b1fd, 32d1335, 209ac0f, fc74074, 7a87995
MueLu: disabling ML MMM by default
Tpetra: CrsGraph, CrsMatrix: Fixed Bug 5978.

Thanks to Clark Dohrmann for discovering this bug and providing a test
case.  Clark's test uses 2 MPI processes.  Process 0 gets a nonzero
number of rows in the row Map, and Process 1 gets zero rows in the row
Map.  The test then creates a graph with that row Map, and with a column
Map equal to that row Map.  Then, only Process 0 calls
insertLocalIndices() to insert a nonzero number of entries into the
graph.  Finally, the test calls fillComplete, supplying domain and range
Maps equal to the row Map.

On both processes, the graph starts neither locally nor globally
indexed.  In the test, only Process 0 calls insertLocalIndices(), since
Process 1 has zero rows.  The very first call to insertLocalIndices() on
Process 0 calls allocateValues(LocalIndices, GraphNotYetAllocated).
This in turn calls allocateIndices(LocalIndices).  This marks the graph
as locally indexed, and as _not_ globally indexed:

indicesAreLocal_  = (lg == LocalIndices);
indicesAreGlobal_ = (lg == GlobalIndices);

When the test calls fillComplete() on the matrix, indices have only been
allocated (i.e., allocateIndices() has been called) only on Process 0,
not on Process 1.  This confuses later parts of fillComplete that expect
the "allocated" and "locally vs. globally indexed" states to be
consistent on all processes.  The result: MPI either hangs in a
collective, or the collective raises an MPI error (e.g.,
MPI_ERR_TRUNCATE).

Here is the fix implemented in this commit:

1.  Change the call to allocateValues in fillComplete (both in CrsGraph
and in CrsMatrix), so that its first argument is LocalIndices if the
matrix has a column Map, or GlobalIndices if the matrix does not have a
column Map.  That way, indices are always allocated on all processes
after this point.

2. That change alone causes processes with an empty graph
(insertLocal{Values,Indices} was never called) to have a different
locally vs. globally indexed state than processes with a nonempty graph.
I fixed this by making makeIndicesLocal an entirely noncollective
method.  In particular, it no longer calls computeIndexState, which does
an all-reduce to line up the locally vs. globally indexed states on all
processes.

The all-reduce mentioned in #2 was entirely unnecessary, because at the
end of fillComplete, the graph / matrix is always locally indexed and
not globally indexed.  Thus, this fix has the pleasant side effect of
removing an all-reduce from fillComplete.