RFC 3588 allowed only 3xxx result codes in an answer-message (that is,
an answer that sets the E-bit) while RFC 6733 also allows 5xxx result
codes. Setting request_errors = answer tells diameter to answer 5xxx
errors itself. Returning {answer_message, integer()} from a
handle_request callback allows both 3xxx and 5xxx result codes to be
set. {protocol_error, integer()} is retained for 3xxx result codes.

Configuring the value 'callback' all errors detected in incoming
requests to result in a handle_request callback. The default value
'answer_3xxx' is the previous behaviour in which diameter answers
protocol errors without a callback.

Instead, use whatever dictionary a transport has configured as
supporting application id 0. This is to support the updated RFC 6733
dictionaries (which bring with them updated records) and also to be able
to transparently support any changed semantics (eg. 5xxx in
answer-message).

To make for easier adding of future options. The record is only passed
into transport modules so the only compatibility issue is with these.
(No issue for diameter_{tcp,sctp} and unlikely but theoretically
possible for any other implementations, which probably don't exist at
this point.)

The module was originally just intended as a minimal callback
implementation that could be used as a template. Being able to order
just a subset of callbacks (with reasonable defaults) makes for
simpler code in many cases however so ready support for this can be
useful.

Should have been included in 5af64c7d57d83ce35bfd7b15ac3ce6ec7459fd73.

The message being encoded and dictionary module are included
by diameter_codec.erl so diameter_gen.hrl doing so was overkill.