`TIME_MON` variable: inconsistent ranges between `2.x` and `3.x` engines.

[M4tteoP]

Describe the bug
Both v2 and v3 docs are reporting the following line about TIME_MON variable:

This variable holds the current month value (0–11). The following rule matches if the month is either November (value 10) or December (value 11)

But Apache docs provide the following:

TIME_MON	The current month (01, ..., 12)

And v2 implementation seems that it is indeed following it (Thanks @airween for the pointer):

rvar->value = apr_psprintf(mptmp, "%02d", tm->tm_mon + 1);

Logs and dumps
Same rule and same request:
v2:

Executing operator "eq" with param "11" against TIME_MON.
Target value: "11"

v3:

(Rule: 800) Executing operator "Eq" with param "11" against TIME_MON.
Target value: "10" (Variable: TIME_MON)

Expected behavior
Consistency across engines, and/or documentation aligned.

Additional context

1. Coraza is implementing TIME variables, and it would be great to come up with a unified behavior across all the engines. I'm personally in favour of ranging between 1-12 as it sounds very natural and as far as I know it is the standard way. E.g. ISO_8601 reports: [MM] indicates a two-digit month of the year, 01 through 12
2. It might be worth another issue, but looks like also TIME_WDAY is not consistent. This time docs are reporting different behaviours:
   This variable holds the current weekday value (1–7), where Monday is 1
This variable holds the current weekday value (0–6). The following rule triggers only on Satur- day and Sunday

[airween]

Additional info: libmodsecurity3 code is here:

    transaction->m_variableTimeMin.assign(std::to_string(timeinfo.tm_mon));

And thanks @M4tteoP for the report!

[airween]

Expected behavior
Consistency across engines, and/or documentation aligned.

I prefer mod_security2's behavior, so I think we should change libmodsecurity3's behavior (and add +1 to the index).

[airween]

See PR #3306.