better heuristics for choosing variables to move to memory

## Description

I've been looking at bytecodes produced using the `--via-ir` pipeline and I noticed that in most cases, popular constants (0, 4, etc.) are pushed to the stack on the function selector code and shared between public functions. I stumbled upon a [contract](https://library.dedaub.com/ethereum/address/0x619f793e2d7e077986d06630c11c6c0563eb28e6/source) where the memory mover kicks in to resolve stack too deep errors. This behavior can be seen in the [produced yul code](https://library.dedaub.com/ethereum/address/0x619f793e2d7e077986d06630c11c6c0563eb28e6/source-yul?line=147), with `0` being stored at memory offset `0xa0`. After this point the constant is loaded 271 times (can be observed by searching "60a051" in the [deployed bytecode](https://library.dedaub.com/ethereum/address/0x619f793e2d7e077986d06630c11c6c0563eb28e6/bytecode)).

So in this case the sequence `60a051` is used instead of `6000`, adding 271 extra bytes to the deployed bytecode. Thought to report it as it will probably be common in large programs.

## Environment

- Compiler version: 0.8.17 (also on 0.8.19)
- Target EVM version (as per compiler settings): london
- Operating system: ubuntu 20.04

## Steps to Reproduce

I got the contract's code concatenated to a single file from [here](https://library.dedaub.com/ethereum/address/0x619f793e2d7e077986d06630c11c6c0563eb28e6/) and compiled using 0.8.19 (after removing imports, etc). The same behavior is present. I'm not posting it here because its too large.

Start with the --via-ir pipeline and the memory mover, reproducing the reported contract behavior from the linked source and deployed bytecode. Compare the generated Yul and bytecode around the 0xa0 store and repeated 60a051 sequence; done means the heuristic avoids unnecessary memory loads without regressing stack-too-deep handling or generated output size.

Written by the indexing model from the issue text.