Support for Roots and Snares in CC Tracker

[ACastanza]

Both Root and Snare alerts are enabled by default. Note that alerting for roots appears to require the basegame "show combat tips" setting to be enabled for some reason.

By default, the following snares are included in the IgnoreList to silence some that were extremely common (therefore noisy) without being particularly informative for the player:

    [8239] = true,    -- Hamstring
    [160949] = true,  -- Warmth (DK Passive)
    [127795] = true,  -- Living Dark (Templar Bubble)
    [101693] = true,  -- Arrow Spray
    [10650] = true,   -- Oil Drenched
    [85656] = true,   -- Harry

[ACastanza]

There seems to be an unresolved edge case which can cause a Snare alert to not be properly removed. This seems to have been introduced in the process of moving Roots before AOEs.

[ACastanza]

Latest push is a test fix for the noted edge case Edit: Still occured. I think this is likely related to the weird shuffling of the Priority[Number].endTime that occurs in the removeCC function. For some unknown reason, in the previous versions, AOE's (PrioritySix in this version), get reset to the PriortyFour.endTime, if removeCC is called when a different CC is active:

        elseif sixthInterval > 0 then
            self.currentCC = 6
            zo_callLater(function() self:RemoveCC(6, PriorityFour.endTime) end, sixthInterval)
            self:OnDraw(PrioritySix.abilityId, PrioritySix.abilityIcon, PrioritySix.hitValue, PrioritySix.result, PrioritySix.abilityName, sixthInterval)
        return

When I added additional priority levels, I also set them to use this same callLater passing the PriorityFour.endTime with their CC level number (i.e. zo_callLater(function() self:RemoveCC(8, PriorityFour.endTime) end, eighthInterval)

I suspect that this is the cause of the issue, but if so I don't know why it would only cause a CC icon to not get removed rarely instead of commonly.

Does anyone have any more insight into the logic here?

I have an alternative version that instead always resets the callLater with the true endTime here (i.e. zo_callLater(function() self:RemoveCC(6, PrioritySix.endTime) end, sixthInterval) , zo_callLater(function() self:RemoveCC(8, PriorityEight.endTime) end, eighthInterval), etc.)

I'll see if this still occurs with this change, it'd be great if someone could explain the original logic.