Remove global state for typechecking patterns

[ncik-roberts]

Replace global variables managed by type_pat with a (mutable) state value that's explicitly passed around. There are a few benefits apart from the obvious "global mutable state is bad":

• now pattern typing is re-entrant, there is a clearer path to supporting module patterns in array/list comprehension
• the checking of or-patterns is a little more straightforward
• this makes it more obviously correct to remove the unnecessary module_patterns_restriction argument from partial_pred, exposed in the mli. (And, I do remove it in this PR.) These two things don't interact in an interesting way (module patterns, exhaustivity checking), and the explicit scoping of the type_pat_state value makes it obvious that we can just ignore module patterns here.

Implementation

The previous discipline was something like:

1. Call reset_pattern to reset the global state
2. Call type_pat (which writes into the global state)
3. Read out the results from the pieces of global state (the global variables pattern_variables, module_variables, and pattern_force)

The discipline is now:

1. Call create_type_pat_state to create tps, a fresh copy of pattern-checking state
2. Call type_pat on tps (which writes into its fields)
3. Read out the results from the fields of tps

Review

I think waiting for @goldfirere makes most sense here, but I'm open to suggestions.

Upstream status

I'm labeling this as "to upstream" but I have a patch ready to do this, so no further action from anyone else is required.

[antalsz]

I gave this a read and it looks good to me; while I don't understand the pattern-matching code, I believe this correctly refactors it to make all the mutable state local

[ncik-roberts]

I talked to Richard, and he doesn't feel like he needs to review this given Antal's and Leo's review. I'll merge this and prepare the corresponding upstream patch.

[ncik-roberts]

Ah, actually I spotted a bug in this. This hasn't yet been merged to main so this is easy to fix --- I'll do so in the branch I merged it into (nroberts.upstream-feedback.remove-typedtree-module-elaboration).

The new code only propagates the pattern_forces generated in the first branch of an or-pattern, which leads to this program being accepted:

type 'a t = G of 'a

let f ((x : 'a) | (x : 'a t)) = ()

(* val f : 'a t -> unit *)

(I don't understand pattern_forces well enough to state whether this is a soundness issue, but it's at minimum a surprising change in behavior, so I'll fix it.)