Use Teuchos::OrdinalTraits<GO>::invalid() in map ctor.

No need to calculate this number; the BlockMap and Map constructors will do it.
Make ProjectIPtoNodalField work with multiple meshSpecs. Temporary HACK.

The parameter Discretization -> Separate Evaluators by Element Block says
whether to associate a MeshSpecStruct with each element block. LCM requires the
value to be true if more than one material is used.

If there is more than one MeshSpecStruct, then multiple response field managers
are created, one for each element block. Each rfm does its own preEvaluate,
evaluateFields, and postEvaluate calls. Right now there is nothing in the code
to distinguish among the element blocks in these calls. Moreover, the separate
response functions have no knowledge of each other, and so cannot pool data.

The use case of interest here is to obtain nodal data to record in the Exodus
file. The bug was that each RF would evaluate the solution over the whole mesh
according to its material. Hence if there are numEB blocks, numEB RFs would be
called, and there would be numEB writes to the field in the Exodus file.

I need to think about how to do this software design properly, but for now I've
hacked in an inelegant fix. The tag "//eb-hack" notes the locations where the
hack is implemented. I'll back out this hack later when I figure out how to do
the design properly.

The hack is mathematically simple. Each ProjectIPtoNodalField RF forms the full
mass matrix M. But each one forms the r.h.s. b_i for only its element block; the
rest of b_i is 0. Then each solves M x_i = b_i. Finally, x = sum_i x_i is
recorded in the Exodus file. This hack is inefficient: it solves numEB problems
instead of 1, the accumulation x += x_i does unnecessary work, and every
evaluator upstream of ProjectIPtoNodalField in the rfm does work over the whole
mesh instead of over just its element block.

I will probably put together a nontrivial correctness test of the whole software
code path leading through ProjectIPtoNodalField, including the case of multiple
element blocks and materials, before I back out this hack and do the design
properly. So far ProjectIPtoNodalField has been tested for correctness only
internally, i.e., ignoring dependent field inputs and the output Exodus file.

I have not yet implemented the hack for IPtoNodalField.
ProjectIPtoNodalField: Rework where new fields are stored.

Move up to Base.