closes #293

Axfr ixfr client

See merge request !280

This reverts commit e774c8a8.

IXFR: falback to AXFR master-side fix

When Knot master replied to IXFR query by AXFR-style IXFR, the response was wrong in two ways:
1. Header was cleared: no ID, no QR flag
2. QTYPE was changed to AXFR

Both are wrong. The header must be set properly and the IXFR QTYPE must be preserved even if the response has the AXFR format (that's the way to distinguish it), see [RFC1995, Section 4](http://tools.ietf.org/html/rfc1995#section-4).

I removed these changes to the packet. But I'm not totally sure that there is no problem now, because the packet-processing is too obscure. @mvavrusa should review this definitely.

Tests pending.

See merge request !278

- Response had the header cleared (no ID and no QR flag).
- Also, the Question was wrongly set to AXFR. It should remain IXFR
  although the response is in AXFR format. (See RFC1995, Section 4)

RRSet from wire refactoring

Refactored conversion functions for parsing RRSet from wire according to older code and moved from/to wire functions to `packet/`. Also unified a bit with the 'to wire' functions (common RDATA-traversing function).

Also takes into account issue #289.

Fixes #228.

See merge request !275

Rrset dump refactoring

See merge request !277

- DNAMEs are now always decompressed and then there's a check if
  compressed and decompressed sizes match, in case they shouldn't have
been decompressed in the first place.

- It is possible to create an RR with compressed DNAME in it, that would
  be actually bigger than 2**16 - 1. I've added a check for that.

- Tests for both mentioned cases pending.

Axfr ixfr

See merge request !276