When there are multiple options for an exit portal, the user must
decide, and the decision gets stored in beam state. That state was only
being cleared when the beam was turned off, but it should be cleared
whenever the step that decision is related to changes (for example, if
the entry portal is rotated).

This also cleans up the storage of these decisions in beam state, moving
them into a portal specific key that the portal item will maintain.

After adding the ability to 'merge beams' using a single exit portal,
I've noticed it introduces some unintended complexity such as allowing a
single beam to merge into itself over and over. Perahaps instead of
adding more complexity to check the beam to make sure it isn't self,
this functionality should instead be split into a separate item which
allows for the merging/splitting of beams, and portals should retain
their much simpler 'only one beam can exist in a given direction at a
time' rule.

Items can now specify 'immutable' in the state configuration, which
should basically act the same as setting each individual modifier key to
false (e.g. movable, toggleable, rotatable, etc). Beam and wall items
will have immutable set by default.

Item IDs are now retained in cache, making them stable IDs. Previously,
item IDs were re-generated when the page was refreshed, which meant that
if an item had been moved its ID could change. The generation and
storage of item IDs on the loading of a puzzle is not stored as a delta,
so it won't show up as a move and won't be undo-able.

Portal logic has been reverted back to just checking if a direction is
already occupied. This means beams cannot be merged through an exit
portal. That functionality will be added later as a separate item.
Additionally, portal directions cache is now cleared if a portal is
moved, since the beams connected to that portal will need to re-evaluate
their histories.

Swap now requires tiles to contain movable items, instead of any items.

This allows the mask to be re-evaluated when it gets dequeued, with the
potential to cancel the mask. This is because state can change in
between when the mask is queued and when it gets processed. For example,
if multiple portals are reached at the same time, the resolution of one
of the portals may cause a subsequent portal mask to no longer be valid.

Still needs test coverage, but I have confirmed that it is solvable as
is. An additional change in this commit is the addition of an "is not
immutable" filter for modifiers when displaying the indicator badge on
tiles. I think the primary purpose of the indicator is to show the user
they can interact with something in that tile, and immutable modifiers
are not interactable, so it just creates noise. The lock and immutable
modifiers mostly apply when moving something anyways.

This also fixes a few bugs:
- when getting color elements for a newly selected tile, if it contained
  merge beams it was throwing an error using step.color instead of
  step.colors.
- the portal collision logic in beam.onCollision was not handling every
  case.
- state index wasn't being updated correctly if keepDelta was false on
  update.
- state actions like undo and redo weren't properly prevented even if
  they were disabled visually. The reset action was also never disabled
  in cases where it should be.
- the puzzle mask queue was not being emptied when the puzzle was
  reloaded, which caused some strange undo/redo behaviors.