Implement the built-in "extras" provider

[autodidaddict]

There's a subtle, but important point with this one. If we implement the extras provider as a standard subscriber to NATS topics, then we'll basically have one extras provider per host, and they'll each respond to all of the requests of the extras provider.

On the other hand, if the extras provider subscribes as a queue subscriber to the specific subject for it, and registers itself during startup, then an extras provider will be randomly chosen from among the hosts in the lattice. Given the way NATS works, we can at least guarantee that the one chosen will be in an optimal path, but will never be local.

In short, the extras provider will incur a network latency penalty just as if it were a "regular" capability provider that was registered and managed externally.

Another alternative is to monitor the namespace and operation for each invocation, and if we see the extras provider, then we can defer those specific invocations to a custom provider.

I prefer the former, where we create a provider that's queue subscribed to the appropriate topic. This will ensure that all provider invocations go through the same code path and we don't end up with all kinds of one-off conditional branches like we had with Actix and the version before it.

[stevelr]

depends on issue #114

[autodidaddict]

Per multiple discussions, we are removing the sequence number generation because of its local nature potentially causing unintended problems as actors scale horizontally (each host would produce its own sequences with potential overlap).

Additionally, we've also decided to rename this contract ID to wasmcloud:builtin:numbergen.