When `TlsSessionInfo` was added, the only way to mark it as a header that
not be rendered was to implement `CustomHeader`, and then implement a method
called `suppressRendering` to return `true`.

Obviously, this semantically didn't make sense since it's not a custom header,
but not long after, a much better, more robust and semantically reasonable
mechanism to ensure it didn't get rendered was provided in:

akka/akka@a93a73e

This added `renderInRequests` and `renderInResponses` flags to headers, along
with the traits `RequestHeader`, `ResponseHeader`, and `SyntheticHeader`. The
Scala `Tls-Session-Info` class was modified to implement `SyntheticHeader`
instead of the Scala `CustomHeader` trait, but the author forgot to modify the
Java `TlsSessionInfo` class to no longer extend the Java `CustomHeader`
class.

This didn't cause any real issue at the time, because there was nowhere that
the Java `CustomHeader` class was returned or accepted by any API calls, or
treated specially in anyway. That was, until akka#4348, which caused the modelled
header lookup method to throw an exception, instead of return `None`, when the
header is not present, if it extends the Java `CustomHeader` class.

So, this change removes `CustomHeader` from the superclass heirarchy of
`TlsSessionInfo`, and instead makes it implement the Scala `HttpHeader` class
directly, like all other headers. As far as I can tell, this should cause no
issues, as `CustomHeader` is otherwise still not treated specially anywhere or
exposed in any API. It would only cause an issue if some end user code tried to
assign it to a `CustomHeader` typed variable, which I don't see any reason to
ever do that.