fix: OnEscaping Exiled and LabAPI bug

[MS-crew]

Description

Describe the changes
This change modifies the default value of the IsAllowed property in the EscapingEventArgs constructor. The primary goal is to improve compatibility with other plugins that implement their own custom escape scenarios (for example: LabAPI). Previously, IsAllowed was explicitly set to false by default for any escape identified as EscapeScenario.CustomEscape, effectively blocking other plugins. This change reverses that logic, setting IsAllowed = true by default for all escape scenarios, adopting an "allow by default, deny by exception" philosophy. This approach is safe because the base game itself performs a final validation after the event, aborting the escape if the final scenario is invalid (None).

What is the current behavior? (You can also link to an open issue here)
Currently, Exiled's EscapingEventArgs constructor automatically sets IsAllowed = false if the game's escape scenario is determined to be EscapeScenario.CustomEscape(for labapi) . This pre emptively blocks any other plugins that rely on custom escape mechanics from functioning correctly, as the escape process is cancelled by Exiled's event before those plugins can execute their logic. This is the root cause of the issue where custom escape plugins only work when Exiled is disabled.

What is the new behavior? (if this is a feature change)
The EscapingEventArgs constructor now sets IsAllowed = true by default for all escape scenarios, including custom ones. This allows other plugins that handle custom escapes to work alongside Exiled without being blocked by default. These plugins can now modify the EscapeScenario as needed. The base game's logic, which executes after our event, will then proceed. Crucially, the base game still includes a final check and will abort the process if the final EscapeScenario is None. Our change correctly allows custom logic to proceed to this vanilla validation checkpoint instead of being blocked prematurely. Plugins can still cancel an escape if they need to by subscribing to the Player.Escaping event and setting ev.IsAllowed = false within their own handler. This makes Exiled's event system a more interoperable framework.

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

Other information:
Now Exiled is doing what Labapi did, so nothing gets broken.
https://discord.com/channels/656673194693885975/1376301959581007964

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
  Exiled Event Location:
  
  How does LabApi :
  

[MS-crew]

@louis1706 I think this messed up some of the processes (Custom item escape handler) . If you can undo this, we can solve this problem by moving the Exiled event after labapi