Add tls.crl_file support for TLS certificate revocation checks

[egershonNvidia]

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):

[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.