Add typing / drop Python < 3.7 support

[nhairs]

This PR adds Python 3.7+ compatible type annotations (dropping support for <3.7 at the same time).

fixes: #56 #60

At a high level the following changes have been made:

• Move to pyproject.toml
• Type annotations for core libraries (dns, bimap, bits, label, buffer, ranges)
• !! Removed a number of type guards !!
  • Part of the philosophy of using type annotations is that callers are responsible for using and respecting them.
  • This isn't fundamentally different to most python where /can/ pass whatever types you want and it's "up to the gods" to if it will work or not.
• Use newer python features / standard library where available
  • f-strings
  • ipaddress module
• Run the black formatter
• Add mkdocstrings compatible docstrings, including adding/updating documentation where needed.
  • includes stubbed mkdocs site with generated API Reference https://nhairs.github.io/dnslib/latest/
• Remove redundant [get,set]_ attributes for properties (mostly on RD classes).
• Added some "shortcut" methods to Buffer for standard tasks.
• Update GHA workflow to run tests on all supported versions

Most major changes in the code are accompanied by Changed in / New in 1.0 in the docstrings.

Test Plan

1. Ensure that run_tests.sh passes without errors
2. Ensure that mypy passes without errors.

Notes

Unfortunately there's not much I can do to get GitHub to detect the renamed and edited files (particularly dns.py), it's probably to do with the number of lines changed.... (old screenshot but you get the idea)

[nhairs]

This PR is mostly done apart from general cleanup things. I might continue to add type annotations to the non-core libraries.

There are substantial changes (including some that might be controversial) so now would be a good time to get some eyes on it.

cc: @paulc

[nhairs]

@paulc - this is ready for review.

Aside:

I've somewhat been thinking about been thinking about the state of this library compared to some of the alternatives - specifically dnspython which appears to be much more actively maintained, more feature complete (with new DNS features / updates).

It kinda raises the question of it would be better to "deprecate" this package and point other users to the more active package (if yes, then we'd probably just close without committing this PR). This would free up your time mean overall there is less duplicated work between the two communities.

Now that said I've not exhaustively gone through dnspython to know if it covers everything that dnslib does, but thought I'd raise it in case we do want to explore doing such a thing.

Finally this isn't a reflection on the quality of this package, having worked through pretty much the whole code base there's some really elegant code in there.

[paulc]

Apologies for the delay responding to this. I appreciate that a huge amount of work has gone into this PR though as I mentioned I don't really have any time to look at this any more and to be honest I'm not sure that I'm really adding any value in this process. Given your last comment and the scale of the changes I'm slightly reluctant to merge this and would agree that the best answer would probably be to leave dnslib as-is in maintenance/frozen mode (for any downstream software that relies on it) and either for you to fork and create a dnslib2 package based on this PR (I'd be happy to to add a pointer in the README recommending people switch over to this) or recommend that people use a different package.