Nodes store complete routes as uint-based types

[PatrickCronin]

We think a uint-based type is possibly more suitable for internally representing a rstrie than the bitslice type (which is currently implemented as []byte). Since we'll need to use uint32 for IPv4 route parts and uint128 (a custom type) for IPv6 route parts, each node will necessary contain a uint32 or a uint128, and thus we think having each node store its complete representation (conceptually, the route that the node represents) instead of just the bits unique to the node without consideration of the nodes and thus bits of the node's parents.

[coveralls]

Pull Request Test Coverage Report for Build 3808664512

• 246 of 281 (87.54%) changed or added relevant lines in 6 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage decreased (-2.8%) to 80.876%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
cmd/routesum/main.go	4	6	66.67%
pkg/routesum/routesum.go	26	29	89.66%
pkg/routesum/uint128/uint128.go	19	25	76.0%
pkg/routesum/routetype/v4.go	58	70	82.86%
pkg/routesum/routetype/v6.go	83	95	87.37%

Files with Coverage Reduction	New Missed Lines	%
pkg/routesum/routesum.go	1	91.11%

Totals
Change from base Build 3807508815:	-2.8%
Covered Lines:	351
Relevant Lines:	434

---

💛 - Coveralls

[PatrickCronin]

Interesting, there's a few issues on the Internet that seem to suggest there was issues with profiling on OS X (I've been using an M1 MacBook Pro). For interest's sake I ran the profiles on an other Xeon-based server running a flavor of linux.

The bitslice program ran faster again, although this time it was closer.

	bitslice-based radix nodes	uint-based complete route nodes
real	43.576s	44.714s
user	59.703s	1m9.716s
sys	1.591s	1.518s

The profiles now contain boxes from the program, so at least I've got something to look at that makes sense.