Consider a component registry pattern

Nobody has claimed this yet.

At a high level, the idea is that all components `fs`, `net`, ... would sit within a top-level registry, thereby allowing convenient inter-dependency (rather than forcing a tree-like shape), without imposing the cost of full arc-rwlocks for _every_ use case.

Importantly, this would allow single-process single-threaded contexts to be able to have almost zero-cost access to things, while the threaded cases will look similar.

More importantly however, it would ensure that users of LiteBox do not have to come up with a storage discipline for the components, and instead simply are registering components into the services.

Roughly speaking, the user would then simply be able to say something like:

```rs
let litebox = LiteBox::new::()
.register::()
.register::()
.finish();
```
and then be able to access things via (as example):
```rs
litebox.get::().socket(...)
```

Obviously, we can provide convenience functions like `litebox.get_network()` or such, and can even provide nicer wrappers to the above builder functionality. But at its core, this would then allow each component to simply hold on to a handle (internally) to the registry, from which it can access other `RegisterableComponent`s.

This would be a win over the current approach which has the user manually needing to store and manage access to the various components (which can lead to some awkwardness, in cases like the 9p client fs, where network access would either need to be stored within the fs component, or there would need to be careful management of arc-rwlocks).

---

Sidenote: I _believe_ the above design is implementable, _however_ there might be some lifetime issues to deal with if we are using [anymap](https://docs.rs/anymap/latest/anymap/index.html) as the underlying idea for it, so I am not 100% sure on the implementation just yet. However, I do believe that the overall effect (if we can provide the above interface) would be a significant improvement.

The issue names no files, tests, or entry points, so start by locating LiteBox's current component storage and access patterns. Review the proposed anymap-based registry and its lifetime and locking implications. Done would mean a settled registry design and an agreed interface for registering and retrieving components without imposing unnecessary synchronization costs.

Written by the indexing model from the issue text.