Refactor update so it works for both kinetic and fluid species

[manauref]

(disclaimer, my understanding of fluid sources is incomplete)
(note, given the input from a weekend slacker I made some edits in the first comment below)

Currently sources, in the sense of App/Sources and the sources table in PlasmaOnCartGrid, are only used by fluids. They apply CollisionlessEmSource and TenMomentRelaxSource (and Jimmy/Liang have a TenMomentGradSource in a the gradient-closure branch). Comments/observations:

1. ``sources`` are currently separated from the rest of the fluid update (``updateInDirection``), and applied (in ``updateSources`` with some fractional time step) before and after (or is it just before/after when using super-time-stepping?) ``updateInDirection`` (in the ``fvDimSplit`` time stepper).
2. In an input file, these fluid sources appear as tables outside of species tables. Even if the source is just a closure term that applies to a single species. This is just because we want to operator-split these terms and treat them as a ``source``.
3. I find it counter intuitive to call all these things sources. I see you are calling them that way because if you write the equations in conservative form, they appear as terms on the RHS (actually this isn't even true for the heat flux in the energy equation). This is unlike what in tokamak fluid and gyrokinetic turbulence codes people call sources (in my experience), which are typically terms that correspond to plasma/energy/momentum sources into the system. I propose we "rename" some, especially as ``sources`` is starting to be used for other even less source-like terms (like closures) just because of the functional location of the ``sources`` table and the operator splitting happening in the time stepper. This is not too dissimilar from something Jimmy or Liang considered, to rename the folder App/Sources to something like App/FluidXXX.

An aside: I'm not a big fan of packing multiple Apps in the same file (e.g. GkField/GkGeometry, MaxwellField/ExternalMaxwellField).

I would like to propose we refactor sources (or several Apps for that matter) using something along these lines:

1. Create something like an App/Forces folder (pls. propose other names too). In that folder we could place CollisionlessEmSource (rename Lorentz Force?) and ExternalMaxwellField.
2. TenMomentRelaxSource, TenMomentGradSource and Diffusion could go into a App/Dissipation folder (pls. propose other names too).
3. Give these Apps, and the collisions Apps as well, another input e.g. applyOp = "pre", "post", "both", "none"/nil. These options indicate:
   • "pre": the operator only gets applied at the beginning of a time step, before the other RK stages, explicit terms, or the rest of the fluid update.
   • "post": like "pre" but applied at the end instead.
   • "both": operator is applied at the beginning and at the end, e.g. with dt/2 time step each, or we could also request (or code default) pre and post dtFracs if necessary.
   • "none"/nil: no operator splitting takes place, and these terms are applied (presumably explicitly) inside the species:advance().
     
     Not all operators will have all of these options, e.g. CollisionlessEmSource may only support applyOp="both".
4. In input files:
   4.1 single-species operators (ones that get computed independently for each species) like Diffusion, Collisions (TenMomentGradSource?) could live inside the species tables.
   4.2 Operators that get computed for all species at once (CollisionlessEmSource) could either
   • live in each species table (with some duplication of code in input files),
   • go in the field table (after all, this App is just dictating how the fields get applied, and one could in the future envision a situation in VM in which the fields are applied implicitly, thus requiring something like CollisionlessEmSource),
   • or we could leave it outside the species tables.
     
     Then we could sort out what gets applied when in PlasmaOnCartGrid, in a similar way to how collisions get sorted out during kinetic species initialization. That is, we would look through species and field tables looking for "sub-Apps" with the input applyOp. If applyOp="pre"/"post"/"both", we put them in preOps and/or postOps tables accordingly. App with applyOp="none"/nil get placed in a corresponding collisions/sources/etc tables inside each species.
5. In fvDimSplit, instead of looping over sources before and after updateInDirection, we would instead loop over preOps and postOps. And inside species we would only advance/apply the collisions/sources/etc that had applyOp="none"/nil.
6. In forwardEuler or the RK steppers, we could also loop over preOps and postOps for cases in which we are applying, for example, diffusion or collisions implicitly/super-time-stepped.

Some motivations:

• Modify App/Sources so that we can put some kinetic sources in there.
• Make changes to PlasmaOnCartGrid to bring fluids and kinetics a little closer.
• Implement support for implicit/supper-time-stepped treatment of diffusion/collisions in RK time steppers.

[manauref]

1. Since there's no plan to run sims with both FV fluids and DG kinetics, I shouldn't worry much about marrying fluid and kinetic sources. So the easiest thing for now may just be:
   • Rename App/Sources to App/FluidSources, and then create App/Sources for things like GkSource and VmSourceReplenish.
   • (Optionally): abstract out a few flags/variables in PlasmaOnCartGrid (e.g. trying) to eliminate some if-statements and make PlasmaOnCartGrid's flow the same for FV fluids & kinetics. Then place all the time-steppers in a separate file/folder. This would simplify PlasmaOnCartGrid by ~200 lines.
2. In order to keep higher-order accuracy in time, the implicit/super-time-stepped treatment of kinetic collisions needs to be embedded in forwardEuler. So instead of the applyOp input I proposed above, we could request something like stepper="explicit"(default), "RKL" (or "super") in the collisions table. This would tell the species and forwardEuler to handle these terms separately.