CUSP, ViennaCL: Fixed wrong behavior of VecAYPX() for CUSP and ViennaCL vectors.

The case alpha == 0.0 was not handled correctly, where a copy y <- x is needed,
but instead a no-op was implemented.

Reported-by: Lawrence Mitchell <lawrence.mitchell@imperial.ac.uk>;
CUSP, ViennaCL: VecAYPX no longer counts flops if alpha == 0.0

This is now more consistent with the CPU case, where copies are not counted as FLOPs.
apparently fixed a overflow bug.
SNESGS: Fix for warning in the GS-Secant code.
PCKACZMARZ: Added a basic Kaczmarz row-projection smoother as a PC
Change verbosity of VecView in parallel to match serial.

In serial, using the INFO or INFO_DETAIL formats in ASCII do not print
the full contents of the vector. In parallel, they do, which is a huge
waste of communication time, and contrary to the docs.
Fix MatDiagonalScale when used on a MatNest.

The MatNest implementation did not correctly account for any of the
scaling vectors being NULL, whereas it works fine for single Mat
objects (serial or parallel).
PCKACZMARZ: Added symmetric application option.
VecView_*_ASCII: close leak for INFO and INFO_DETAIL

Add unit test for -vec_view ascii::ascii_info

Reported-by: Barry Smith <bsmith@mcs.anl.gov>
MatNest: use PetscCalloc1 instead of manual PetscMemzero
VecView_MPI_ASCII: avoid PetscObjectGetName unless really needed

Historically, VecView output has not included names, but the previous
change to eagerly call PetscObjectGetName() changed output like

  -Vec Object: 2 MPI processes
  +Vec Object:Vec_0x84000005_0 2 MPI processes

This commit reverts to only name vectors when necessary.  It fixes the
previously-inconsistent behavior where ranks other than 0 neglected to
call PetscObjectGetName for PETSC_VIEWER_ASCII_VTK and
PETSC_VIEWER_ASCII_VTK_CELL.

Reported-by: Barry Smith <bsmith@mcs.anl.gov>
PCKACZMARZ: Sign mistake for symmetric application
SNES: Removed now-extraneous fnorm variable from SNESApplyPC()

Since c1c75074e128c85b53ed5ce1f9b329b0e4d789b9 the fnorm argument
has been unused.  Fix documentation also.

Reported-by: Barry Smith <bsmith@mcs.anl.gov>
DM: Fix for recursive DMDestroy() causing valgrind issues

runex26_2 in src/ts/examples/tutorials caused the following valgrind output:

> ==21447== Invalid read of size 8
> ==21447==    at 0x599093E: DMDestroy (dm.c:401)
> ==21447==    by 0x4F3F83F: PetscObjectDereference (inherit.c:612)
> ==21447==    by 0x4F30C6A: PetscObjectListDestroy (olist.c:160)
> ==21447==    by 0x4F3AA1F: PetscHeaderDestroy_Private (inherit.c:117)
> ==21447==    by 0x5184D16: VecDestroy (vector.c:499)
> ==21447==    by 0x5990EA5: DMDestroy (dm.c:425)
> ==21447==    by 0x5B2833D: PCDestroy (precon.c:122)
> ==21447==    by 0x5C0D6EF: KSPDestroy (itfunc.c:772)
> ==21447==    by 0x5C93387: SNESDestroy (snes.c:2790)
> ==21447==    by 0x5D35130: SNESReset_NASM (nasm.c:46)
> ==21447==    by 0x5C92705: SNESReset (snes.c:2732)
> ==21447==    by 0x5C92689: SNESReset (snes.c:2728)
> ==21447==    by 0x5DA00E8: TSReset (ts.c:1872)
> ==21447==    by 0x5DA09EB: TSDestroy (ts.c:1912)
> ==21447==    by 0x402671: main (ex26.c:172)
> ==21447==  Address 0x9b39778 is 24 bytes inside a block of size 32 free'd
> ==21447==    at 0x4C2A82E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==21447==    by 0x4F85AEB: PetscFreeAlign (mal.c:70)
> ==21447==    by 0x5990F29: DMDestroy (dm.c:426)
> ==21447==    by 0x5B2833D: PCDestroy (precon.c:122)
> ==21447==    by 0x5C0D6EF: KSPDestroy (itfunc.c:772)
> ==21447==    by 0x5C93387: SNESDestroy (snes.c:2790)
> ==21447==    by 0x5D35130: SNESReset_NASM (nasm.c:46)
> ==21447==    by 0x5C92705: SNESReset (snes.c:2732)
> ==21447==    by 0x5C92689: SNESReset (snes.c:2728)
> ==21447==    by 0x5DA00E8: TSReset (ts.c:1872)
> ==21447==    by 0x5DA09EB: TSDestroy (ts.c:1912)
> ==21447==    by 0x402671: main (ex26.c:172)

This was caused by recursive calls to DMDestroy().  When freeing the named local vector list, the linked list is freed
before being set to NULL.  The recursive call of DMDestroy() by VecDestroy() then tries to access the value in the
structure.  The fix to this is to zero out the DM member before the recursive call instead of after it.

Reported-by: Barry Smith <bsmith@mcs.anl.gov>
PetscLayoutSetBlockSize: allow PETSC_DECIDE for use when block size has already been set

This slightly simplifies logic in some places, where otherwise we would
have to MatGetBlockSize() and pass it back in.
Mat & Vec: make block sizes lazy

In the past, MatSetUp eagerly set the block sizes (to 1) if not already
set.  This prevents use of the "convenience" constructors because they
call MatSetUp before returning.  We could add bs as an explicit argument
to those constructors, but block size is an extraneous concept for most
users.  The default value of the block size is -1, so now we use
PetscAbs(map->bs) anywhere it is not known in advance that bs has been
explicitly set.  This allows block sizes to be lazy, and they can be set
arbitrarily late, so long as the new size is compatible with the
existing distribution.  For (S)BAIJ matrices, the block size is
structural so it gets set explicitly and can thus be referenced directly
rather than via MatGetBlockSize or wrapped in PetscAbs.
DMPlex: quash -Wmaybe-uninitialized
DMPlex: quash more -Wmaybe-uninitialized
makefile: cleanup targets using SOURCE SOURCEALL and SOURCED
build: split cxx [legacy] build target via SOURCECXX