Add tls.crl_file support for TLS certificate revocation checks

**Is your feature request related to a problem? Please describe.**
Fluent Bit supports TLS/mTLS via options such as `tls.ca_file`, `tls.crt_file`, and `tls.verify`, but there is no way to configure Certificate Revocation List (CRL) validation. In environments that rely on CRL-based revocation (rather than or in addition to OCSP), operators cannot reject revoked client or server certificates during the TLS handshake.
We hit this when deploying Fluent Bit as an mTLS log receiver: our PKI issues CRLs and other components (e.g. Envoy) already honor them, but Fluent Bit accepts revoked client certificates because CRL checking is not exposed in configuration.

**Describe the solution you'd like**

Add a new TLS configuration property:
- `tls.crl_file` — absolute path to a PEM-encoded CRL file
Behavior:
- Available on input and output plugins that support the shared TLS config map (same scope as `tls.ca_file`).
- When set, load the CRL into the OpenSSL certificate store and enable CRL verification (`X509_V_FLAG_CRL_CHECK` and `X509_V_FLAG_CRL_CHECK_ALL`).
- When not set, behavior is unchanged (no CRL checking).
- Invalid or empty CRL files should fail TLS setup with a clear error.
Example configuration (TCP input with mTLS + CRL):
```ini
[INPUT]
Name tcp
Listen 0.0.0.0
Port 5170
Format json
tls On
tls.verify On
tls.crt_file /path/to/server.crt
tls.key_file /path/to/server.key
tls.ca_file /path/to/ca.crt
tls.crl_file /path/to/crl.pem
```

**Describe alternatives you've considered**
* OCSP stapling / OCSP responder: not always available in private PKIs; our infrastructure standardizes on CRL distribution.
* External proxy terminating mTLS: adds operational complexity; we prefer native support in Fluent Bit like other TLS options.
* Pre-filtering at CA issuance: does not handle post-issuance revocation.

**Additional context**
I have a working implementation on branch elad-master-tls-crl-support in my Fork:
https://github.com/egershonNvidia/fluent-bit/tree/elad-master-tls-crl-support

TLS backend hook:
- flb_tls_set_crl_file() + OpenSSL implementation
- Input/output property parsing for tls.crl_file
- Internal unit tests (mock TLS backend dispatch)
- Runtime tests (in_tcp): valid client cert accepted, revoked client cert rejected during handshake (TLS 1.2 client-auth path)
Because `tls.crl_file` loads the CRL into the TLS context's certificate store, CRL verification applies to any connection created from that context, this includes the upstream HTTP client used by HTTP-based output plugins (out_http, out_es, etc.), not just raw TCP inputs/outputs. The runtime tests exercise the TCP input mTLS path directly, but the mechanism is context-wide.

Review the existing implementation on the elad-master-tls-crl-support branch, starting with flb_tls_set_crl_file(), the OpenSSL backend hook, and the input/output property parsing for tls.crl_file. Run the internal mock TLS tests and the in_tcp runtime tests. Done means valid client certificates still connect, revoked certificates are rejected, invalid or empty CRLs fail setup, and unset CRL configuration preserves existing behavior.

Written by the indexing model from the issue text.