Memoise mk_prec_matrix

[mrichards30]

Hi, I was playing around with some vibe coded profiling/flame graph tools I got Claude to put into my copy of PolyML, and found a few places when building theories that seem pretty straight forward to optimise. The first of them is that building the precedence matrix for the term parser in mk_prec_matrix shows up a surprising amount in the flame graph.

Here, mk_prec_matrix is in pink and it's showing as 11.4% of the build.

So it seems like the precedence matrix is being rebuilt a bit more often than it needs to. In this PR I've memoised it so it only re-computes when grammar rules and "specials" are changed (the only two fields mk_prec_matrix reads). This is cutting my build time (building kernel, core_theories, and more_theories) from an average of 957s to 876s.

After the change the flame graph shows mk_prec_matrix having gone down to 2.1% (still in pink).

[ordinarymath]

Can this be done by having the partial application not become stale for useless updates like defining a constant instead?

[mn200]

I think I'd prefer a world where the matrix is stored in the grammar as an option ref value. If :

1. a new grammar is calculated from an old one,
2. the change is one that won't require a recalculation, and
3. there is a matrix already associated with the old grammar,

then the new grammar's pointer can point to the old matrix. Otherwise, the new grammar either gets a fresh pointer with NONE in it (change requires a recalculation), or the new grammar gets to copy the pointer.

Subsequently, the parse_term function's call to mk_prec_matrix looks at that reference and either uses what's there, or calculates it once.

If the rest of parse_term's prefix was super-quick (doubtful), this would also remove the need for the current code in Parse to track whether or not the grammar has been changed.