cache_ban: Forward compatibility for the binary ban representation

[nigoroll]

Our ban expressions (like obj.age > 20s) are represented in a binary format (see top of cache_ban.h) which allows for forward compatibility, yet at the respective places we currently just trigger an assertion failure if we hit an unknown argument or operator code.

This commit brings forward compatibility such that, when bans are loaded from persistent storage into older code which does not yet support newly introduced binary codes, we no longer panic.

Ban evaluation:

For bans, evaluating an expression to true is always "correct" in that the cache would not deliver banned content. It might cause objects to be removed from cache, but that is at least not incorrect. So the fail safe action this code takes is to always evaluate unknown ban expressions to true.

CLI ban.list:

For unsupported ban expressions, the unknown argument or operator codes are formatted as (0x%02x) with the string UNSUPPORTED as the user-specified argument. For example:

	1740567193.765849     0 -  (0x20) > UNSUPPORTED && obj.http.foo ~ 377.266

(note that here the operator > is supported and printed as such, and the ban contains one unsupported and one supported expression)

Logging:

For each unsupported argument or operator code, an Error VSL is output exactly once to vxid 0.

Statistics:

Whenever unsupported argument or operator codes are encountered, the newly added counters MAIN.bans_inval_arg1 and MAIN.bans_inval_oper are incremented, respectively.

Fixes #4288

[nigoroll]

bugwash: phk wants to think about it