Feature Request (v2): Add support for TX variables for ipMatch operator

[EsadCetiner]

Feature

libModSecurity3 supports the use of transaction collection variables as an value when using the ipMatch operator, this isn't the case for ModSecurity2.
For example. these rules work on libModSecurity3 but not on ModSecurity2:

SecAction \
    "id:1,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    setvar:'tx.allowed-ips=1.1.1.1'"

SecRule REMOTE_ADDR "@ipMatch %{tx.allowed-ips}" \
    "id:9508032,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    ctl:ruleRemoveById=920300,\
    ctl:ruleRemoveById=920320,\
    ctl:ruleRemoveById=920330,\
    ctl:ruleRemoveTargetById=920120;FILES_NAMES,\
    ctl:ruleRemoveTargetById=920121;FILES_NAMES,\
    ctl:ruleRemoveTargetById=922130;MULTIPART_PART_HEADERS"

Another issue I encountered was you can't use semicolons within an setvar action, this issue happens on both engines and makes referencing IPv6 addresses via a variable unusable. I'm not sure if I'm doing something wrong here but I feel like this should work.

SecAction \
    "id:1,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    setvar:'tx.allowed-ips=1.1.1.1,::1'"

SecRule REMOTE_ADDR "@ipMatch %{tx.allowed-ips}" \
    "id:9508032,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    ctl:ruleRemoveById=920300,\
    ctl:ruleRemoveById=920320,\
    ctl:ruleRemoveById=920330,\
    ctl:ruleRemoveTargetById=920120;FILES_NAMES,\
    ctl:ruleRemoveTargetById=920121;FILES_NAMES,\
    ctl:ruleRemoveTargetById=922130;MULTIPART_PART_HEADERS"

Use Case:

This is yet another issue with the CRS Nextcloud plugin, this feature in particular is needed to disable certain rules for the server itself. There's no way to know what the server's IP might be in advance, so this needs to be an configuration option. For now this is documented in the readme but it does complicate the installation process and requires end users to manually update the rule if changes are ever made to it.

Maybe there's a better way to do what I'm trying to do, but this feels like the easiest for the end user as all they'd need to change is a single variable in the plugin config file.