Use value types for class and type in DNS entries to make them immune to parameter order bugs

I just spent a few hours debugging why I was getting garbage responses from my embryonic jetty-based DNS server, and found it was because I had CLASS and TYPE reversed when passing them to `DnsResource`'s constructor.  Having two `int` parameters next to each other which mean very different things is dangerous and exactly what Java types are there to help avoid.

So that nobody else has this problem, I've created this patch which adds two classes, `DnsType` and `DnsClass` which are wrappers for the protocol values (and also have names).  Includes tests which pass and patches the rest of netty-dns to use them.
Can I ask why?  I get that stylistically some people think that's a good idea, but in this case
 - Its not subclassable (check style growled at me finalling equals and hashCode in an already final class [in case the class were ever un-finalled], so the package private constructor + factory method was my workaround)
 - The problem area is *extremely* well defined
   - I.e. accessors don't solve any problem - like having a rectangle class with a `numPoints()` method just in case someone creates a 5-pointed rectangle - not going to happen

I'll do it if you insist, but it adds pointless verbosity.