feat: More Dynamic Spawn Locations

[SnivyFilms]

Description

Describe the changes
Adds a new Dynamic Spawn Location for Custom Items/Roles, adding SCP 127 Lab Room, Inside127Lab.
Marks InsideHidLower to obsolete due to the door being removed.
Changed InsideHidUpper to InsideHidLab.

What is the current behavior? (You can also link to an open issue here)

What is the new behavior? (if this is a feature change)
Adds a new Dynamic Spawn Location for Custom Items/Roles, adding SCP 127 Lab Room, Inside127Lab.

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Other information:
Any projects that references InsideHidUpper will have to change it to InsideHidLab, however preexisting configs will not need to worry about changing anything, since its an enum.

Tested on Linux only (although it should work on Windows just fine)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentations

Submission checklist

• I have checked the project can be compiled
• I have tested my changes and it worked as expected

Patches (if there are any changes related to Harmony patches)

• I have checked no IL patching errors in the console

Other

• Still requires more testing

[louis1706]

Make it Obsolete and add new one for HidLab since it's not the same door

[SnivyFilms]

Making a new enum entry (InsideHidLab) instead of replacing InsideHidUpper will require anyone that uses InsideHidUpper to manually replace each instance to InsideHidLab, regardless if its configs or in the IDE. Whereas changing it from InsideHidUpper to InsideHidLab which is functionally the same door will only need someone to change it in their IDE when coding the plugin, since its an enum

[louis1706]

Making a new enum entry (InsideHidLab) instead of replacing InsideHidUpper will require anyone that uses InsideHidUpper to manually replace each instance to InsideHidLab, regardless if its configs or in the IDE. Whereas changing it from InsideHidUpper to InsideHidLab which is functionally the same door will only need someone to change it in their IDE when coding the plugin, since its an enum

Inside Hid Lab is the microHid door right?

[SnivyFilms]

It goes into the main room (unkeycarded) not the room that players picks up the MicroHID itself which is behind a keycard door, which is InsideHidChamber.

Simple action list for door encounters for MicroHID: Goes up stairs -> Open HID_LAB (used to be HID_UPPER) then player opens HID_CHAMBER to access and pickup the MicroHID.

As such I believe that just renaming InsideHidUpper to InsideHidLab is reasonable instead of making a new entry and marking InsideHidUpper as obsolete, since mechanically they are the same door, even if it has a different name.