Add message.go, peer.go and bucket.go files to
kadcast implementation.

Includes:
- makePeer
- addIp
- addPort
- addID
- computePeerDistance

`Bucket` has now a dynamic array of peers instead of a fixed-
length one.

Implemented `Tree` struct which holds the routing info containing
the L `Bucket` structures.

Implemented for `Tree`:
- makeTree
- addPeer

Implemented:
`idXor` which computes the XOR between to `Peer` ID's.
`collapseDistance` which allows to classify the
XOR distance in one of the L `Bucket` that the `Peer`
holds into the ROUTING `Tree`.

Implemented tests for `idXor` function.

- `Peer` distance is expressed now as `uint16` to hold the
max range value `128` unsoported on the `byte` type.
- Instead of using math logarithms, we work with bitwise ops.

- `collapseDistance` has been ranamed as `classifyDistance` and
optimized since now only counts the ammount of `1` of a byte that
comes from an XOR op.
- `idXor` just performs the XOR between the two `Peer-ID` arrays
and computes the number of different bits on the result, using this
counter as the result for the distance classification value.
NOTE that this value has the range (0 - 128] to match the `L-buckets`.

The ID matches the 16 first bytes of the output that
comes from applying the sha3-256 to the Wallet's Pk
as a 32-byte array input.

In order to implement LRU for Bucket managing,
we need to use arrays whoose key is a Peer and
since one of it's fields was a Slice (IP field)
we will now represent it as a 4-byte array.

Implemented almost all of the LRU-continuous
policy with optimizations done to avoid array
looping by using maps.

Finnished the implementation for `Bucket`.
Everytime we need to add a Peer, now it is done
under this policy which is specified on the Kadcast
paper.

- makeTree allocates space for a new routing tree
and sets it's own Peer info on the lowest order
bucket.
- addPeer computes the distance between it's own
peer info and the other peer to be included.
Then it adds the peer to its corresponding bucket

If the peer it's the same as our peer, the function
simply doesn't do anything.

This functions allow us to move from UDP packet style
to Peer network info style/types.

This function should be responsible of getting
a received UDP packet, parse it and also
call the needed processes according to the packet.

This function takes a tree and gets the UDPAddr data
of the peer that is running the node.

Refactored all of the functions to return and get
inputs and outputs as references or pointers in
order to save memory and to not copy thoose values
everytime on the stack on each function call.

This is needed in order to compute the IdNonce of
each Peer.

Now the tree holds the k-buckets and also:
- Peer info in `Peer` fmt.
- Peer UDP info as `UDPAddr`
- Peer Id Nonce.

Refactored the makeTree function to build the
propper `Tree` with our personal Peer info.

This two messages are used to test if a peer
is actually connected or not to the network.

The function that converts uint32 to bytes was using
references, so it setted the nonce to 0 everytime.
This has been solved and everything works now.

With this setup, it takes aprox 1min to compute the ID
on an Intel Core i5-7x series.

Now the Peer constructor gets the externalIP
address of the peer and a port and computes
the ID returning the whole Peer struct.

Since we can get the local UDP Addr quickly, there's
no need to pass it as a parameter.

- Now sendUDPPacket gets the parameters per value instead
of by-reference.

processPacket now it's just a debugging tool to catch
the packets recieved and print the content.

Refactored function arguments to be used by value
and not by reference.
Moved UDPAddr<->PeerInfo transformations.

`Router` holds the Routing tree data structure and
also quick access to the owner `Peer` info.

Added `sendPing` and `sendPong` methods passing and
recieving arguments by-value

Most of the tests are actually used just with
debugging and networking testing.

When a Peer recieves a packet, it can veriofy that
the nonce attached to it really corresponds to the
PoW process that a Peer has to accomplish before it
can join the network.

The function now verifies that the Nonce has been
computed correctly and then returns:
- Peer if the Nonce is correct
- Error if not.

Implements basic functions to work with
packets as:
- getHeadersInfo => Returns the headers sliced
in the 3 different elements.
- processPacket => gets a Packet and processes
it according to it's type.
- getPacketFromStream => Gets a stream of bytes
and returns a Packet struct from it.

Since the node that receives a ping, only knows the port
where the packet was sent, it does not know on which port
the sender is listening for the UDP response. And since it
is not possible to writte to a port that you are listening,
we need to send the listeningPort in the headers.

This also allows to update it.

PeerSort struct aims to be a helper data
structure that allows the implementation
to order the PeerList of a Node in terms of
XOR-distance in respect to a certain Peer.

The struct has the same fields as the `Peer`
struct plus a `xorMyPeer` field which represents
the XOR-distance of this specific `Peer` in respect
to another.

Refactored some Distance functions to use values
instead of references.

Also implemented `xoirIsBigger` in order to be
able to order XOR-distances between two peers
represented with [16]byte.

- Implemented sort.Interface for `ByXORDist`
that allows to sort slices of Peers by it's
XOR-distance.
- getPeerSortDist allows to get a list of
`PeerSort` items ready to be sorted by it's
XOR-distance in respect to some `Peer`.
- `getXClosestPeersTo` allows to get the selected
number of peers that is closer to the specified Peer.

Also implemented `FIND_NODES` message sender
function. Which gets the `alpha` closest nodes
to the Peer that runs the node and sends them
a `FIND_NODES` packet.

The function was accessing an invalid position.

Now it's solved and the `FIND_NODES` messages are
tested and working propperly.

`setNodesPayload` allows to create the payload
of a `NODES` message filled with the number of
peers sent and the peers themselfs on a serialized
format

Allows to serialize a Peer in bytes in order to
be sent inside a packet.

The method automatically gets `K` nodes from it's
buckets that are closer to the selected target Peer,
constructs a `NODES` packet and sends it over the
network.

We can translate a Peer to bytes to send in wire
format and viceversa.

- `checkNodesPayloadConsistency` allows to
verify if a `NODES` message is consistent
in terms of `numPeersAnounced * bytesPerPeer <=> len
of the payload`.
- `getNodesPayloadInfo` returns a slice of Peers
collected from a `NODES` message payload.

The peers sent on the `getXClosestPeersTo` was
higher than the number of peers specified in the
function's arguments.
It has been corrected.

Now it iterates through the range and gets the peercount
of each bucket.

Attempts to get closest nodes on each round until
it does not get a closest to the previous round.

Then we consider the process has finnished.

Now the process does 3 attempts trying to
bootstrap the network and add the network
bootstrapping nodes to it's buckets if they
respond with a `PONG`.

- `CheckNodesConsistency` now uses BigEndian for
decoding.

- `getNodesPayloadInfo` is now adjusted to get the
Peers propperly from the payload.

Now the parser just gets the ammount of peers that
it's announced instead of consuming the whole
slice of bytes of the packet (1024B)

This allows to se/derialize the red packets from the
listener gorutine and the packetConsumer gorutine.

Packet <-> ByteSlice

Instead of spawning gorutines for each new
connection, we just add the received packet
to the circularqueue and the consumer will
take care of them.

The `Put` method sends a signal to the consumer
to awake and start consumming and processing
packets from the queue so we are not constantly
waiting.

Now processPacket is a gorutine that consumes
packets received for the UDPListener and then
processes them as is needed.

This saves us to spawn a gorutine for every single
packet the node receives.

Now that the application works on a syncronous
way, we don't need to protect the buckets with a
mutex since onli `processPacket` will acces to them
and will do it syncronously since the refactor has been
finnished.

Since there's no reason to pass the whole router to the
UDPListener, we just send our peerInfo.

Now if deserialization from the queue fails,
we will just break and go for the next iteration
of the packetQueue.

This cleans the entire implementation in order to be
merged.

Modified the code according to the changes
suggested by @autholykos in the review of
 #141.