Introduce generic linked list

[StephenButtolph]

Why this should be merged

Improves the performance of linked.Hashmap#Put by ~50%.

Before:

Benchmark_Hashmap-12    	 6913144	       166.5 ns/op	      80 B/op	       2 allocs/op

After:

Benchmark_Hashmap-12    	13979869	        82.58 ns/op	       0 B/op	       0 allocs/op

How this works

Previously, the linked.Hashmap depended on the "container/list" library. This resulted in 2 memory allocations.

1. For the creation of the keyValue struct that was wrapped into an any interface.
2. For the creation of the list.Element struct enforced by the list functions.

By implementing our own version of the linked list, we are able to use generics to avoid the memory allocation for the interface conversion.

Additionally, our version of the linked list allows allocating the Element externally to the list. This allows the Hashmap to maintain a free list (which isn't an increase in memory pressure, because the map never frees allocated space either).

How this was tested

• Added unit tests
• Added Hashmap benchmark
• CI

[abi87]

I understand this is supposed to be a drop in replacement of containers/list, still let me ask a question.

• Wouldn't it be more natural to have methods to add a value (PushFront/Back InsertBefore/After) accepting a value T instead of a ListElement[T]?
• Wouldn't it be more idiomatic to signal "no next/prev element" via an error rather than a nil pointer? I guess here performance considerations may have prevailed

[StephenButtolph]

All of the methods take in ListElement rather than T to allow the caller to manage all memory allocations. I'll add some helpers to expose the API with allocations.

[StephenButtolph]

Aside from the ListElement vs T change, I kept the signature the same as the stdlib to allow ease of switching. (Which is why we use nil to signal no element rather than a bool.

[abi87]

just nits and questions, but LGTM