Move radius logic out of Chewie

[samrussell]

The radius serialising/deserialising code mirrors the EAP code but there are enough differences that they should probably follow different patterns.

One of the things with the EAP code is that it's stateless so can be done out of a bunch of static class methods, whereas the radius deserialisation needs things like the packet_id_to_request_authenticator lookup. Passing a callback two layers through a method call is a red flag and a sign that this function probably lives closer to the deserialiser.

Going from this

chewie -> radius packer/unpacker (with callbacks back to chewie)

To this

chewie -> radius lifecycle -> radius packer/unpacker

The lifecycle-packer/unpacker relationship could be done a number of ways, but the key is for that to be its own object that Chewie doesn't know or care about.

[samrussell]

#82 is the first step here, the next is probably to rethink how the current radius parsing/validation lifecycle works as a lot of state gets passed in quite deep that could be handled differently.