Core: Region connection helpers

[alwaysintreble]

Please format your title with what portion of the project this pull request is
targeting and what it's changing.

ex. "MyGame4: implement new game" or "Docs: add new guide for customizing MyGame3"

What is this fixing or adding?

Region.connect and Region.create_exit. latter returns an entrance that can be used for other things (?) and former allows easy connection between two regions without needing the full structure of add_exits. Also added deprecation warning to creating Entrance elsewhere, since there's a ton of duplicated code from people doing so. Made it a separate commit so it can be easily dropped if desired.

How was this tested?

unit tests and checking that the logs print the warning correctly

If this makes graphical changes, please attach screenshots.

[el-u]

• Is it a good idea to inspect the stack on every entrance cration?
• How is this gonna work out for users of custom subclasses of Entrance? (Those can't be created using these new methods, so they'd still have to create them manually. And if they follow the recommended practice of calling super().__init__, they will be hit with the deprecation message as well.)
• Can Region.add_exits be rewritten to use Region.connect inside the for-loop in order to reduce code duplication?
• I found the argument name exiting_region confusing since this is supposed to be the region that the entrance will lead to, not the one it is exiting from.

[alwaysintreble]

• Is it a good idea to inspect the stack on every entrance cration?

Probably not but this was the first thing I thought of. I'm open to a better way to handle this.

• How is this gonna work out for users of custom subclasses of Entrance? (Those can't be created using these new methods, so they'd still have to create them manually. And if they follow the recommended practice of calling super().__init__, they will be hit with the deprecation message as well.)

Could update create exit so it accepts a class like add_locations or alternatively it could just be subclassed. I feel like if you're subclassing Entrance, you're likely subclassing Region already.

[ThePhar]

I'm not a fan of marking direct Entrance creation as "deprecated". Obviously, want to encourage folks to use the AP helper methods, but if folks know what they're doing and have good reason to, I don't want to nag them with a deprecation warning, implying it's going to be removed.

And that's better than making a monster of a helper method that can handle every possible use case.

[alwaysintreble]

I'll drop the warning once a decision is made on how to handle it. I can't think of any reason why someone would still need to create them manually here, though I'm willing to concede it being a possibility. I also know that people won't change or use any of the "proper" API as long as the old stuff exists and works.
Also edit: i realized the assert here didn't work, so I put it at the end of my add_exits after making sure to call super and it passed lmao

[el-u]

There's a bit of an asymmetry between add_locations, which takes the location_type as an argument, and create_exit, which reads the entrance_type from an attribute.

[alwaysintreble]

I think the asymmetry is ok. There's use cases where we might want multiple Location classes in a Region (Messenger already does this), though very unlikely we have the same for Entrances.

[black-sliver]

Think this is fine now. Further improvements can be done on top of this without breaking backwards compat.

Adding a warning / deprecating the old way of things should be opened as separate PR and merged once we know for sure this solution is flexible enough to update all worlds.