Changing 'd' content type to RFC 1035 name broke omapi-key parsing

We overlooked three server options with 'd' format: omapi-key, ldap-port, ldap-init-retry. Changing 'd' under #2 (closed) from being handled as text, breaks the ability to match omapi-key to any parsed keys. When server config file defines a TSIG key to use with omapi such as shown below:

# define a key
key  toms-key {
        algorithm hmac-md5;
        secret <some key here>;
}

# tell the server to use the key for omapi
omapi-key toms-key;

With a "d" option format for omapi-key, during configuration parsing the server will emit the error "OMAPI key : not found" and then exit. This is because the value for omapi-key option when evaluated by the server is in RFC 1035 format "\007toms-key" rather than plain text "toms-key". Changing the format to "t" will solve the problem. This should work for all three as prior #2 (closed), "d" format content equivalent to plain text.

This will need to go to v4_1_esv too.