Avoid false positive SLEPc detection

If we seem to have SLEPc, but there's some reason we can't scarf build
configuration from SLEPc, then we really don't have SLEPc.

I got caught by this when trying a new PETSC_ARCH for which I hadn't
yet built SLEPc.
Grote, 2013
Add DofMap::local_variable_indices()
Added LinearSolver::init_names()
KSPSetOptionsPrefix calls PCSetOptionsPrefix

So we don't need to do so redundantly
Check for errors, simplify code
Command line option for solver names
Add names support to NewtonSolver
Optional name argument to FooSolver::init()
Support --solver_system_names
DiffSystem --solver_system_names works now
LinearImplicitSystem --solver_system_names works
Fix cut-and-paste mistake
Fix use of freed data.  pc_type fieldsplit works
Prepare to factor out petsc_auto_fieldsplit code
Factor out petsc_auto_fieldsplit code
Trying to add --solver_group_foo options

Not working yet, but need to checkpoint here.
Use consistent name for old PETSc case
Postpone library-level init() as late as possible

That way we don't preclude a physics-aware init(Matrix) from user
code.

This will hopefully fix some MOOSE regressions
Got Schur complement fieldsplit working

The two last catches:

libMesh::on_command_line didn't work the way I had assumed, so I
replaced it with code that does.

For multiplicative and schur fieldsplits, PETSc really cares what
order you declare fields in.  But we can get arbitrary order by simply
putting everything in a group, because std::map orders groups
alphabetically and libMesh declares group fields in container order.