Correct handling of zone files containing nodes with inconsistent case

This merge request addresses a design flaw in IBDNS which caused the server to serve incomplete resource record sets when said sets were entered into the zone file with inconsistent owner name casing.

Consider the following example zone file:

$TTL 3600
$ORIGIN domain.example.

@         IN  SOA  […]

hello     IN  TXT  "lowercase"
HELLO     IN  TXT  "uppercase"

sub       IN  NS   ns1.somewhere-else.example.
SUB       IN  NS   ns2.somewhere-else.example.

Because of that flaw, answers to TXT queries to hello.domain.example only contained one of the two TXT records, and referrals in reply to queries to sub.domain.example or one of its subdomains only contained one of the two NS records.

The root cause of this issue was a design deficiency in the IBDNS.Catalog data structure. The structure works by keeping a mapping of keys to values, where the keys are recorded in their original spellings, alongside another map, mapping a lowercased key to one key in its original case. The latter mapping is changed from a one-to-one to a one-to-many mapping. Then, new functions were introduced so as to access all key-to-value mapping for all equivalent spellings of a given key. Finally, the functions implementing lookups of authoritative data and referral data in zone files, which rely on IBDNS.Catalog, are modified in order to take advantage of those new functions.

Problems were also witnessed in the detection and handling of illegal aliases: either combinations of CNAME and non-CNAME resource records whose owner names only differed by case, or multiple CNAME resource records with that property, were not properly detected as bad aliases and did not cause IBDNS to SERVFAIL in its default configuration. That is fixed by this merge request as well.

This merge request also introduces unit tests that reproduced the problems caused by the design flaw. All unit tests should now pass.

Fixes #34 (closed).