Describe the bug
MessageResponseBuilder::error_msg allows to construct a response message with a given response code. The implementation fails to set the EDNS options if the response code requires EDNS.

To Reproduce
Steps to reproduce the behavior:

A minimal implementation of RequestHandler for the server crate:

impl trust_dns_server::server::RequestHandler for Handler {
    type ResponseFuture = future::Ready<()>;

    fn handle_request<R: ResponseHandler>(
        &self,
        request: trust_dns_server::server::Request,
        response_handle: R,
    ) -> Self::ResponseFuture {
        let request_message = request.message;
        if let Some(req_edns) = request_message.edns() {
            let response = MessageResponseBuilder::new(Some(request_message.raw_queries()));
            let our_version = 0;
            if req_edns.version() > our_version {
                response_handle
                    .send_response(response.error_msg(
                        request_message.id(),
                        request_message.op_code(),
                        ResponseCode::BADVERS,
                    ))
                    .unwrap();
                return future::ready(());
            }
        } else {
            todo!()
        }
    }
}

This code should produce a DNS response with the status code BADVERS but it does not create a EDNS record, thus it will end up as NOERROR. The lower 4 bit of BADVERS are all 0 which maps to the NOERROR value.

Expected behavior
Silently changing the response code is very bad. I can see two possible solutions here:

1. Silently add a EDNS record to the message and set the high response code there.
   This would be the most developer friendly solution. If a EDNS record already exists it simply sets the high bits. This could lead to a situation where the server response with a EDNS record even if the client didn't specify EDNS support. But these "extended" response codes only make sense in the presence of EDNS.
2. Return an error when setting a response code which requires EDNS. This would require to change the function signature to return a Result<_, _>.

One problem with both solutions is that MessageResponse::set_edns allows to overwrite the EDNS record of the response after setting the correct response code bits. This again could silently alter the intended response code.

Version:
Crate: server
Version: 0.20.0-alpha.1 and main

Additional context

The same problem is also present in trust_dns_server::authority::Catalog (0.20.0-alpha.1 and main).
https://github.com/bluejekyll/trust-dns/blob/48f625ad0de450329fcf628db779b21ae6eddfda/crates/server/src/authority/catalog.rs#L94-L124
Here the problem is not related to the use of error_msg, but the code implements the behavior manually and forgets to set the high response code in the EDNS record.

The documentation for Header::set_response_code hints that it does not support all response codes. The documentation could be improved with a link to EDNS and a small example how to properly set any response code.