%{RULE.*} expands to an empty string in tag and some other actions and operator parameters #3742

Describe the bug

#3734 makes %{RULE.*} work in setvar, expirevar, msg, logdata and the dynamic collection keys, and in every kind of rule (SecRule, SecAction, SecRuleScript). Other places still expand their macros without the rule, so %{RULE.id}, %{RULE.msg} etc. are empty there, in every kind of rule:

All of them call m_string->evaluate(t) instead of m_string->evaluate(t, rule).

tag is the one most likely to matter, eg. tag:'rule-%{RULE.id}' to group the log entries by rule. The others are unlikely to use %{RULE.*}, but they should behave the same.

To Reproduce

SecRuleEngine On
SecDebugLogLevel 9
SecRule ARGS:a "@streq test" "id:100,phase:1,pass,log,tag:'rule-%{RULE.id}'"

curl "http://localhost/?a=test"

Expected behavior

The debug log contains Rule tag: rule-100, and the error log entry contains [tag "rule-100"].

Actual behavior

The debug log contains Rule tag: rule-, and the error log entry contains [tag "rule-"].

Server (please complete the following information):

• ModSecurity version (and connector): libModSecurity v3/master (after fix: expand %{RULE.*} in SecAction and SecRuleScript rules #3734), all connectors

Additional context

• For the actions, the fix is the same one-liner as in fix: expand %{RULE.*} in SecAction and SecRuleScript rules #3734: pass the rule, m_string->evaluate(t, rule). Tag::getName() is also called from other places, so it needs the rule as a parameter.
• Operator parameters need more work: Operator::evaluate(Transaction *, RuleWithActions *, const std::string &, RuleMessage &) drops the rule and calls evaluate(transaction, str), so the rule has to be passed through to each operator that expands its parameter.
• Msg::data() and LogData::data() (src/actions/msg.cc:60, src/actions/log_data.cc:40) also expand without the rule. That's intentional: fix: expand %{RULE.*} in SecAction and SecRuleScript rules #3734 keeps them unchanged for RuleWithActions::msg() and logData().
• Each fix needs a regression case, like the ones in test/test-cases/regression/variable-RULE.json.

Related: #3733, #3734.