Validate TLS certificate files contain valid PEM data at startup

[lukebakken]

RabbitMQ currently accepts invalid TLS certificate files at startup without validation, only failing silently when clients attempt to connect. This occurs because Erlang's TLS implementation lazily loads certificates on first connection rather than at configuration time. Users may not discover misconfigured certificates until production traffic fails.

This change adds a pem_file validator to the cuttlefish schema that reads certificate files and validates they contain valid PEM data using public_key:pem_decode/1. The validator rejects empty files and files without valid PEM entries, causing RabbitMQ to fail at startup with a clear error message identifying the invalid file.

The validator applies to all TLS certificate file mappings across 6 schema files: cacertfile, certfile, and keyfile for main listeners, definitions import, syslog, HTTP auth backend, LDAP auth backend, and peer discovery (Consul, etcd, Kubernetes). DH parameter files continue using the existing file_accessible validator since they are not PEM-encoded certificates.

Fixes #15065

[michaelklishin]

Can these fixture files be renamed to reflect that they are "server certificates" in the EKUs sense?

Looking at the direction the industry is going, I would not be surprised if we were to introduce a key usage validation on top, and in that case knowing which fixture file has which EKUs just from the name would help.

And well, tls-gen already names the files it produces that way, so we can just copy a few valid certificates and keys with a 10 year expiration.

[lukebakken]

@michaelklishin @Zerpet I'm going to do one last review for PEM settings that are "sneaky" like oauth2's signing_keys

[lukebakken]

FYI there is a deps/rabbitmq_prometheus/test/config_schema_SUITE_data/schema directory that I deleted since it seems like those were added by mistake a while ago.