Have a `GrudgeDOFArray`?

There's a lot of awkwardness in the grudge interface from having to repeatedly specify DOF descriptors (`DOFDesc`s). This is the case because `DOFArray`s don't know the DOF descriptor with which they're associated. (They can't. `DOFArray`s are defined in meshmode, and in order to make sense of a DOF descriptor, you need a catalog of discretizations, something like grudge's `DiscretizationCollection`.)

The idea here is to fix that by introducing a grudge-specific subclass of the `DOFArray` that does have that information. This would declutter the interface a lot, in many places. There may be some aspects of easier-said-than-done here:

- [ ] Would we allow arithmetic like `DOFArray + GrudgeDOFArray`? (I'm thinking no.)
- [ ] What happens if the user passes a `GrudgeDOFArray` to a meshmode function? (This is still well-defined, since it'd be a subclass. But would meshmode be able to return a `GrudgeDOFArray`? I'm thinking no. As a result, grudge users probably shouldn't be calling meshmode directly for anything, i.e. we'd possibly need some wrapper code. I don't know how wide-spread this would be.)
- [ ] `grudge.op` was just in the process of asking users to explicitly specify `DOFDesc`s. We would effectively re-un-deprecate the "bare" versions and re-deprecate the explicit versions. We can keep those around for a while, they just need to check that if a `GrudgeDOFArray` is passed in, its `DOFDesc` matches the passed parameter. This is mostly mechanical work, I think.

Anyone opposed?

cc @MTCam @alexfikl @a-alveyblanc @lukeolson @majosm @anderson2981 @matthiasdiener