Document optimizer side-effect guarantees

## Abstract

The bytecode produced by the optimizer by design does not have to preserve all the side-effects of the original. We currently do not document which effects those are specifically, which leads users to report irrelevant discrepancies as bugs. We should list them somewhere in [The Optimizer docs](https://docs.soliditylang.org/en/develop/internals/optimizer.html) and provide the rationale.

Here's an initial list, which may be incomplete - thinking this through is an integral part of the task:
- gas usage (optimizer assumes unlimited gas)
- in particular, it's possible for optimization to eliminate an out-of-gas revert
- bytecode size
- number of items on stack
- warm/cold slots (#16445)
- memory expansion (`MSIZE`)
- offsets of instructions, data section, metadata, etc. within the bytecode (`PC`)
- presence of unused data and assemblies inside bytecode
- presence of unused data inside memory
- removal of ineffective state-modifying code (e.g. `SSTORE` that writes the same value, so has no effect, but would revert in a `STATICCALL`).

We may also want to include aspects of unspecified behavior. For example:
- Order of evaluation within a single statement
- Revert reason (e.g. failure due to not enough data returned vs explicit check that a contract does not exist)

Start with the Optimizer documentation at docs.soliditylang.org/en/develop/internals/optimizer.html and review the listed side effects and unspecified behaviors. Check which items need inclusion and rationale, then document the finalized guarantees and non-guarantees so users can distinguish optimizer behavior from bugs.

Written by the indexing model from the issue text.