Add new Portal constructor

[ghost]

• Add new Portal consructor that accepts a weenieClassId and Position object
• Add PortalWeenie enum for Floating City, Golem Sanctum, Humming Crystal, and The Orphanage portals, for use with the new Portal constructor
• Modified the /createportal debug command to use the new Portal constructor and the Humming Crystal weenie as a PoC
  TODO: add a TTL to the portal, so it gets removed after a length of time

[ghost]

Last minute change that occurred to me that I should probably restrict the weenie given to this new constructor to specific known weenies that are portals and not leave it open to all weenies, especially those that aren't even portal objects.

[Mogwai-TheFurry]

So, this should use the existing portal objects, it just gets a dynamic ID and, doesn't show on radar, has a different color, and has an expiration. I don't see the need for a new object type here. Can you elaborate on why you did it that way?

[ghost]

These special portals don't have a complete ace_object/ace_portal_object, as they shouldn't be spawning with the other static/fixed portals. Instead of having the work of creating a dynamically generated ace_portal_object performed outside of the Portal class, I thought it would be easiest to move the logic into another constructor overload that can dynamically build the ace_portal_object from a weenie, defined by the enum, and a position object.

[ghost]

I was also thinking of using a similar approach in the SummonedPortal class, with the player summoned portals, but take the portal coordinates from the appropriate character PositionType table on gateway creation.

[Mogwai-TheFurry]

There's the rub, though. Temporary portals never need persisting in the database, and don't need data-mapped objects. They're just a different constructor that (maybe) has a weenie for a white/summoned portal with all the associated rules of a temporary portal. Summoning a portal should only ever load a weenie, not some one-off SubPortal object.