feat: add opcodes to flip storage slot privacy flag (assembly-only)

## Summary Add two new opcodes that allow inline assembly users to explicitly change a storage slot's privacy flag. These would bypass the current CSTORE/SSTORE restrictions (e.g. CSTORE reverts on non-zero public slots, SSTORE reverts on private slots). ## Motivation Currently there is no way to convert a non-zero public slot to private, or a private slot to public. The FlaggedStorage access control rules prevent this for safety, but advanced users writing inline assembly may have legitimate reasons to reclassify a slot (e.g. migrating storage during an upgrade). ## Proposed Opcodes Names should be extremely explicit about what they do, both for developers and auditors reviewing contracts: | Opcode | Description | |---|---| | `MAKE_SLOT_PRIVATE` | Flips a slot's flag to private, preserving its value. Works regardless of current flag. | | `MAKE_SLOT_PUBLIC` | Flips a slot's flag to public, preserving its value. Works regardless of current flag. | Open to alternative naming — the key requirement is that the name makes the danger immediately obvious to anyone reading the assembly (including auditors). Some alternatives: - `FORCE_SLOT_PRIVATE` / `FORCE_SLOT_PUBLIC` - `RECLASSIFY_PRIVATE` / `RECLASSIFY_PUBLIC` ## Danger These opcodes can break privacy guarantees if misused: - `MAKE_SLOT_PUBLIC` on a slot containing a secret exposes it to `SLOAD` by any external observer - `MAKE_SLOT_PRIVATE` on a public slot hides data that may have already been observed These should only be available via inline assembly — the compiler should never generate them for normal Solidity code.