Draft: Add new classes: Ipv[4,6]NetworkAddress, aimed at (slowly) supersede Ipv4Mask and Ipv6Prefix

I already know the main objection: why do we need this.

1. !2642 already goes in this direction (simplify)
2. A mask (or a prefix) don't have sense without the Address they are referring to. The new classes (ideally) clarify this.
3. This will simplify a LOT some operations.

The adoption of these classes doesn't mean that we're deprecating Ipv4Mask and Ipv6Prefix soon, it will be slow (and painful, for the ones that do it) process. As an example of stuff that could be radically changed (in better):

• Ipv[4,6]RoutingTableEntry (smaller footprint).
• Ipv[4,6]InterfaceAddress (smaller footprint, cleaner API).
• Routing protocol procedures (network routes are almost always passed as CIDR).
• Several protocols (cleaner APIs).
• <Add here your enhancement.>

Just as an example of what I'm talking about...

        if (j->GetRouteStatus() == RipRoutingTableEntry::RIP_VALID)
        {
            Ipv4Mask mask = j->GetDestNetworkMask();
            uint16_t maskLen = mask.GetPrefixLength();
            Ipv4Address entry = j->GetDestNetwork();

            NS_LOG_LOGIC("Searching for route to " << dst << ", mask length " << maskLen);

            if (mask.IsMatch(dst, entry))

Why IsMatch is a function of Ipv4Mask? It doesn't make any sense.

New version:

        if (j->GetRouteStatus() == RipRoutingTableEntry::RIP_VALID)
        {
            auto network = j->GetDestNetwork();
            uint16_t networkLength = network.GetNetworkLength();

            NS_LOG_LOGIC("Searching for route to " << dst << ", mask length " << networkLength);

            if (network.Includes(dst))

which is, honestly, way more readable, logic, and error-proof.