Performance question -- related to visit NURBS and VectorFE bug fix.

[IdoAkkerman]

I love using Visit to visualize MFEM results, not in the least because it (used to) natively allows visualization of NURBS solution.
Using LOD/MutliResControl allows refining the visualization on the fly (like the magic CSI enhance:)), however this seems to have resulted in a regression incapabilities. I think I have a fix for the problems introduced with the MutliResControl, but before suggesting it to the ViSit team I would your input.

The orginal code for upscaling the solution reads as:

    mfem::OperatorHandle hi_to_lo;
    lo_fes.GetTransferOperator(*ho_fes, hi_to_lo);
    hi_to_lo.Ptr()->Mult(*gf, lo_gf);

where the original gf solution is projection on the low-order refined lo_gf. This approach does not seem to work for NURBS or VectorFE spaces.

My suggestion is to use instead:

    if (gf->VectorDim() == 1 )
    {
       mfem::GridFunctionCoefficient gf_cf(gf);
       lo_gf.ProjectCoefficient(gf_cf);
    }
    else
    {
       mfem::VectorGridFunctionCoefficient gf_cf(gf);
       lo_gf.ProjectCoefficient(gf_cf);
    }

My questions are as follows:

1. Is this an acceptable fix, in terms of improved capability vs (potential) performance loss.
2. Is this the intended use of GetTransferOperator?
   2.1) Is the visit use case covered by another type of Transfer Operator?
   2.2) If not should that be implemented? Via perhaps the routines I just sketched out?

[IdoAkkerman]

in the branch add-generic-transfer I coded a transfer operator based on the same ideas above. This will create a slightly cleaner interface with visit I believe.

Is this the right usage of the Transfer classes?
@dylan-copeland @justinlaughlin Is there overlap with NURBSIntegrator?
I think not directly as it is basically going in the other direction, but perhaps testing the capabilities requires a very similar unit test?