allow creating labels from different threads (#97)

By allocating label metadata from thread-shared memory, we can allow the
creation of new labels from any thread. Though metrics must still be
registered from the main thread, general usage after registration
becomes more flexible.

A downside of this approach is that memory for labels (and friends) is
no longer managed by the GC meaning that it potentially leaks should one
wish to release the registry - this does not have much practical impact
since registered metrics typically stay around until the application
ends but could have an impact on applications using custom registries.

Fixing the leak would require introducing an API for manually releasing
the shared resources, an excercise left for the future.

A more forceful refactoring would also make `Collector` non-ref - this
would allow registering new collectors from different threads as well
making the library fully thread safe (at the expense of some breaking
changes).

Of note is that we perform label lookups using a sorted sequence instead
of a `Table` - this should make no practical difference since label
cardinality is expected to be kept low.

Author: arnetheduck