This variant is never constructed by us. When we encounter invalid field
code, we throw an error.

Seriously doubt anyone uses this and this will also allow us to drop
`FieldCode::Invalid` in the following commit.

A message with an invalid field code will just fail to deserialize so we
don't need to represent this state.

Seriously doubt anyone uses this and this will also allow us to drop
`message::Type::Invalid` in the following commit.

An invalid message will just fail to deserialize so we don't need to
represent this state.

We'll be using these to avoid having to deserialize header and individual
fields repeatedly.

As it is now based on the internal fields cache and doesn't involve
deserializing the header.

We now construct the Header from fields cache and primary header clone.

This variant is never constructed anymore and hence useless.

We could just deprecate it only but the chances of someone using this in
client code are very low so let's not bother.

We now construct the fields from the cache.

They are not anymore.

Since we construct the fields from the cache.

Since we construct the header from the cache now.

Since we either construct the header from the cache now or deserialize
from raw bytes and the deserialization will fail if the message has
fields with incorrect codes (the only possible issue here).

They'll be deprecated in a following commit.

Not only is the performance of the direct fields getters no longer much
worse than the getting the fields through the header, but also field
getters on the header are much faster the that of Message.

Moreover, I've ideas on how to make the header getter even faster.

I don't see users having much need for this and we're about to make
`Field*` API private.

We don't need this method internally, doubt anyone uses it and we're
about to turn Field* API private anyway.

We don't need this method internally, doubt anyone uses it and we're
about to turn Field* API private anyway.

This exposes way too much internal details about the protocol that users
do not need. The specific field getters we provide are sufficient for
any low-level code.

I wrote most of this when I was still very new to Rust and I started
with a very bottoms-up approach. Hence we these API had been public
until now.

I doubt anyone uses these anyway so chances of people's code breaking
are low but even if they do, it's a API breaking release.