Mark apply1 inline

Apparently some recent changes caused the compiler to not inline it,
which causes optcheck to fail.

Merge pull request #5616 from unisonweb/fix/optchecks

Mark apply1 inline

Merge pull request #5600 from unisonweb/25-02-24-dependencies

use full names in `dependencies` output

Merge pull request #5582 from unisonweb/cp/fix-bad-prior-migration

Don't use last_accessed column in migrations prior to version 18

Merge pull request #5574 from unisonweb/fix/sandboxed-pre-eval

Reworked pattern compilation

This is when #5557 was merged. We need a stable identifier for this build so we
can release it on Unison Cloud before clients pick up the change.

Merge pull request #5557 from unisonweb/topic/pattern-compilation

Rework data pattern matching to use default cases

Merge pull request #5529 from unisonweb/fix/gh-workflow

Merge pull request #5528 from unisonweb/fix-5525

Do reference-based pruning for ucm compile, turn back on inlining

The pruning was causing problems with compiled programs when
inlining was on, because it would prune based on the inlined
code. The inlined code may have certain intermediate combinators
omitted, but those are still necessary to have a full picture of
the source code. Since `compile` was using the MCode numbering
and backing out which References are necessary from that, it
would throw away the source code for these intermediate
definitions. This then caused problems when e.g. cloud (running
from a compiled build) would try to send code to other
environments. It wouldn't have the intermediate terms necessary
for the remote environment to do its own
intermediate->interpreter step.

This new approach does all the 'necessary terms' tracing at the
intermediate level, and then instead determines which MCode level
defintions are necessary from that. This means that the pruning
is no longer sensitive to the inlining. So, it should be safe to
turn inlining back on.