The Witness: Add info about which door items exist in the pool to slot data

[NewSoupVi]

Right now, slot data contains this info:

1. Every possible door item -> Doors it unlocks
2. Unlockable doors for which some item exists that unlocks them in this slot's itempool

This is not enough to identify, client-side, which door items exist in the itempool, because there are multiple door items that can unlock any given door, depending on options.

So, this replaces the "door hexes for which items exist in the pool" slot_data entry with "door items that exist in the pool". From this, "Unlockable doors for which some item exists that unlocks them" can be inferred (with the help of disabled_entities as well), and the appropriate change has been made client side.

This allows a new client side feature that displays in-game what item a door is locked by, which aids in hinting.
It also should be a slight memory use reduction on average, as the amount of door items is always less than or equal to the amount of doors they unlock.

A new client release has been made to support the slot_data change.
https://github.com/NewSoupVi/The-Witness-Randomizer-for-Archipelago/releases/tag/v6.0.0p9

[NewSoupVi]

Drafting because this solution is incompatible with #2916, where a door item might not open a specific door despite the door not being disabled

[NewSoupVi]

I now know how I want to solve the conflict, and merging either PR will (correctly) create a merge conflict on the other, so I'll leave both open.

[NewSoupVi]

As of the release of https://github.com/NewSoupVi/The-Witness-Randomizer-for-Archipelago/releases/tag/v6.0.0, this is technically a bug fix, because I fucked up the backcompat on the new client.
(I'm investigating a client side partial revert / workaround as well though)

[Exempt-Medic]

Merged into main and just printed out the IDs, they now properly match the options being used and show the item IDs for panel/door items that exist in the pool. Also connected to a game with it and things seemed fine

[NewSoupVi]

Adding some positive data:

People have been playing with this in an apworld for months, and it has not caused any issues with door shuffle - The "locked by" feature also seems to work as intended (well, the client-side position detection has some kinks still, but that has nothing to do with the changes from this PR)