add Location trigger

[Boneshockx]

Description

This pull request will add a new trigger "Player Location" with filters related to zones and instances.
Since the "Conditions" trigger already contained several instance filters, these are now moved to the Player Location trigger.

I've added code to Modernize.lua that removes the instance filters from Conditions and creates a new Player Location trigger.
If the leftover Conditions trigger contains no active filters as a result of this, it is removed.
Instance filters in Conditions triggers have a "deprecated" string added and auras with these are show an AuraWarning. #4917 (comment)

Also fixes #4759

Location filters

• Player Location ID(s): The same one as in Load, with added functionality to toggle recursive child maps on/off
• Recursive: toggle only shows if the above input contains an id prefixed with c eg. c1978
• Zone Name: This leaves open the ability to filter by name instead of IDs
• Subzone Name: minimap zone text
• Map Type
• Indoors
• Instance Name: hidden but stored in state %instance
• Instance Size Type
• Instance Difficulty: now also stored in state %instanceDifficulty
• Instance Type

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested

The Modernize has been tested with this aura: https://wago.io/qDhHF9TX-
It contains 2 triggers:

1. Condition trigger with "Alive" and "Instance Size Type" checked
2. Condition trigger with "Instance Difficulty" checked

After importing this aura, two new triggers are added and the 2nd condition trigger is removed:
3. Player Location trigger with "Instance Size Type" checked
4. Player Location trigger with "Instance Difficulty" checked

[InfusOnWoW]

I don't think you can realistically move these settings to a different trigger, there are too many cases that you canot accurately convert. So the options are,

1. adding them all in the conditions trigger
2. adding them to a new trigger, and leaving the conditions trigger unchanged

[Boneshockx]

I like @emptyrivers idea.
Don't delete the filters from a Conditions trigger, but instead deprecate them and migrate to a new Player Location trigger.
We could then show an AuraWarning to notify players to update their aura before it breaks:

[Boneshockx]

The latest commit will not remove the instance filters from the Conditions trigger.
Instead, on migration it will create new Player Location trigger(s) if instance filters are found in the aura.
An AuraWarning is shown that the aura has migrated instance filters to the Player Location trigger.

[mrbuds]

I don't want this merge with this migration

[Boneshockx]

I can drop the migration if you'd rather not have it. I thought of it as a convenience before you mentioned texts, conditions and trigger activation.
Though I do prefer to have the instance filters in the player location trigger, and eventually remove those from the conditions trigger after a while.

[Boneshockx]

@InfusOnWoW I think I tackled all your reviews now.
I added MapType initially to check for caves, though I added IsIndoors which is better at checking this and it makes the MapType option redundant, so I removed that.

I've removed the AuraWarning for having instance filters enabled in the conditions trigger. The red deprecated text remains with an additional description to guide users to the location trigger. Since the instance filters are multiselect options I had to make sure it uses arg.desc. This overwrites the multiselect description, but if you prefer to concatenate the two descriptions together then let me know and I will change it.

[Boneshockx]

I wasn't able to find anything about VEHICLE_UPDATE being required. I'm not sure why it's being used for the load option.
I've tried pet battling, went to the darkmoon faire rides, did a quest somewhere in stonetalon mountains that forces you in a vehicle.

[InfusOnWoW]

The vehicle update comes from b57179727940d1fb539bccd5f690c9ceb6847f09. The bosses there are from the Eternal Palace raid in Bfa. So no idea whether this is still a problem worth considering. I'd say leaving it out is fine.

I looked at what events are fired on moving inside and I don't see a better event. My conclusion from that is though, that we shouldn't have an inside trigger option. I don't want to build a trigger on an seemingly unrelated event without a good reason.

(The good reason for using VEHICLE_UPDATE for zone id/name was that it previously worked that way and users had auras relying on us using the event.)

The inside check is not something I have ever seen anyone ask for nor do I see that as crucial. so given that there's no useable event for it, I'd say leave it out.

[InfusOnWoW]

I've added a small commit fixing an lua error I encountered while testing and making the parsing function easier to understand (at least I think so).

[jjholleman]

@InfusOnWoW I've removed the Indoors option.

Now, something a bit unrelated. While developing this trigger, I wasn't using the Player Location ID filter at first. I had them all split up in their own trigger options. So that made a big list of filters and I had the idea of adding a divider to split the map related filters and the instance filters. Just like in an Aura Trigger where you have categories for Spell Selection Filters, Affected Unit Filters and such. However, it seems like the header type from BuffTrigger is not available in Prototypes. Is that something I can convince you to add? If not, I think I would rather remove the "Instance Filters" text.

[InfusOnWoW]

The BuffTrigger 2 options directly use AceOptions, whereas the GenericTrigger doesn't directly use AceOptions, but instead is converted to AceOptions via "ConstructOptions".

ConstructOptions currently doesn't support a "header" type, but adding that is trivial, by just adding code e.g. similar to

elseif (arg.type == "header") then
        options["header_"..name] = {
          type = "header",
          width = WeakAuras.doubleWidth,
          name = arg.display,
          order = order,
          hidden = hidden,
        }
        order = order + 1