TLS: structured certificate selection result for async certificate callbacks

Currently async TLS certificate callbacks rely entirely on mutating `SslRef`.
When certificate selection fails or is rejected, the resulting TLS accept error
can be difficult to diagnose because the callback cannot explicitly communicate
its outcome.

This is a small proposal to improve diagnostics for async certificate selection.

This proposal introduces a structured result for certificate selection:

```rust
enum TlsCertificateSelection {
Selected,
Rejected { reason: String },
NoSelection,
}
```

`TlsAccept` would gain an optional method:

```rust
async fn certificate_callback_result(
&self,
ssl: &mut TlsRef,
) -> TlsCertificateSelection
```

New implementations could return explicit outcomes, while existing
`certificate_callback()` implementations would remain supported.

Legacy callbacks mutate `SslRef` directly, so the TLS server handshake layer
would infer success when certificate material was installed even if the
callback returned `NoSelection`.

This would allow TLS accept to produce clearer diagnostics for cases such as:

* explicit callback rejection
* callback returning without selecting a certificate
* callback reporting success without installing certificate material

The listener API remains backend-agnostic; certificate inspection and legacy
inference stay in the TLS server handshake implementation.

**Scope**

This change currently applies only to the OpenSSL/BoringSSL TLS server
implementation (`openssl_derived`). Other TLS backends (rustls, s2n, noop)
are unaffected because async certificate selection currently operates on
`SslRef` in the OpenSSL path.

If this direction looks reasonable, I can open a PR with a working implementation.