Revamp `interpretH`

[KingoftheHomeless]

interpretH is:

• Very confusing to newcomers and experienced users alike
• Clunky to use even if you know what you're doing.
• Not quite powerful enough for some purposes

We need to fix it. The most conservative approach would be to implement an alternative interpretH -- something like #384 -- that addresses these issues without changing interpretH itself; a more radical approach would be to replace interpretH entirely.

Either way, this will be part of the ever-expanding list of issues that v2 should cover. We need to do some work on this to figure out what the best alternate interface would be. My proposal is the following:

interpretHGood :: (  forall z q x
                   . (forall x. z y -> Sem (Opaque q ': r) y)
                  -> e z x
                  -> Sem (Opaque q ': r) x
                  )
               -> Sem (e ': r) a
               -> Sem r a

but that implementation requires an extensive rework of the library's internals. This also shouldn't replace interpretH entirely, because there are some power interpretH gains from access to the functorial state that this doesn't have.

For v2, we should at the very least implement a simple stop-gap like #384. If we're able to come up with a satisfying replacement for interpretH in time for v2, we'll include it; otherwise, we'll have it as a long-term goal.

[tek]

another approach @googleson78 and I talked about was to stick the machinery from #384 into Tactics, like the inspector is. do you see a problem with that, or would you consider it a worse solution?

[KingoftheHomeless]

I'm in favour of it. #384 relies on running the interpreter recursively automatically, which Tactics doesn't currently support. We should be able to extend it to be able to, though.
What should the naming schema be? runTSimple and bindTSimple?

[KingoftheHomeless]

There's also the question about how such an extension would interact with #239, but my opinion is that we cross that bridge when we come to it. At the very worst, we have to give up unification of Strategy and Tactics, which isn't ideal, but isn't that bad either.

[tek]

I think the names should be something like interpret(Nested|HigherOrder|Embedded), reflecting that the current interpreter is run as well as that the thunk's Sem has a different r than the result type.
Of course those names are a mouthful and I'm not sure what terms are really intuitive…