This isn't expected to result in a significant increase in memory use,
so for now it's enabled by default. Elaboration chains where it is not
desired to preserve origins can delete the `origins` attribute from
the fragment and nothing will be stored.
The interface `Fragment.origins` remains private, as is the rest of
the `Fragment` interface (including itself), but it enables certain
codebases that currently use a much more invasive technique to rely on
reading a single private field.
Use _EnumDict._member_names to determine which members to consider.
This way we don't need to redo sunder/dunder checks, and `nonmember`s
(introduced in py3.11) are correctly excluded.
This is a defacto public API, given it remains usable from py3.8
until py3.12 inclusive. (_member_names changes from a list to a
keys-only dict for performance reasons in py3.11, but they iterate the
same.) In current Python main (i.e. what will most likely be 3.13), a
"member_names" property is added which returns those keys.
I originally picked :pc: as it is short for "python code", but it is
obscure and :py: is not taken, so a much more obvious role can be used
instead. Also, we all typo :pc: as :py: all the time anyway.
In this environment it's not feasible, or at least it's not documented
how, to distribute JavaScript code by packaging it as a wheel; only
Wasm code (as shared objects) can be distributed this way. The current
`amaranth-yosys` strategy would not work even though wheels can be
installed on Pyodide, and Yosys will need to be explicitly provided by
the environment instead.
The implementation is sufficiently generic that non-Pyodide hosts could
potentially make use of it, though it doesn't seem like any exist at
the moment.
In some environments (e.g. Pyodide) it may be advantageous to not load
this library, and with the import at file level, it makes the entire
simulator unusable, not just `PySimEngine.write_vcd`.
This might also help people whose Python environments are unusually
broken, whom we've historically accommodated.
