previously, "else" was considered a "pattern primitive", even though it
is valid in both the pattern and the type pattern Problems. And
"with-unknown-macro" was considered a "universal primitive", because it
works in any Problem.

Now, a "pattern primitive" means a pattern which is _only_ valid in the
pattern Problem, and a "type pattern primitive" (a new term!) means a
pattern which is _only_ valid in the type pattern Problem. There are no
such primitives yet, but I plan to add a type pattern primitive, this
commit is in preparation for that.

Finally, a "poly-problem primitive" now means a primitive which works in
more than one Problem; all of them in the case of "with-unknown-type",
and two of them in the case of "else".

forkAwaitingTypeCase schedules a job which (eventually) executes the
Macro actions which follow the type-case. shifting the phase before
forking did cause that Macro action to be executed in a shifted phase,
but also had the unintended effect of shifting the phase at which to
interpret the Syntax returned by the macro. The solution: don't shift
the fork call, but do shift the Macro action it eventually executes.

I want to add a type pattern macro in phase 1 which matches on a type
constructor in phase 0. The only way to lookup a type constructor is to
expand the name of that type constructor (so that hygiene rules apply
properly). That means we now need macros which return type constructors,
not types nor type patterns.

test command:

ghcid --test=':set -XOverloadedStrings' --test='ShortShow.shortShow $ Core.Core $ Core.CoreDataCase (Syntax.SrcLoc.SrcLoc "" (Syntax.SrcLoc.SrcPos 0 0) (Syntax.SrcLoc.SrcPos 0 0)) (Core.Core $ Core.CoreInteger 42) [(Core.DataPattern $ Core.DataCtorPattern (Datatype.Constructor (ModuleName.KernelName ModuleName.kernelName) "just") [], Core.Core $ Core.CoreInteger 42)]'