Reorganise module structure

We have agreed that we should, in the near future, reorganise the structure of this package - the current structure results in a lot of interdependencies and long imports. The latter is at least partially addressed by moving symbols up to the top level, but improving the structure would still be very helpful.

This issue is to provide somewhere we can discuss that structure before I launch into rearranging things - of course I anticipate that issues will arise when it's implemented that change the plan, but hopefully having a good plan to start from means any deviations can be discussed more efficiently.

There are some bits of code that will be used from lots of the codebase but have no onward dependencies. These probably should exist in their own modules at top level:

• exceptions can centralise all the exceptions we need (no dependencies outside standard library)
• utilities has various useful bits and pieces, it probably stays where it is but should be restructured to have an empty __init__. It may be sensible to rename it with a leading underscore to mark it as private.
• introspection makes up a lot of the utilities code and arguably would do well in its own submodule labthings_fastapi._introspection. Again, this should be marked as an implementation detail.

I anticipate these might all need to be imported from quite a few other places, including some submodules that will need to use a .. import. However, as long as they clearly have no onward dependencies within the module, that feels OK.

I think we need a module for types, or maybe two.

• An internal _types module, which could include things like an interface between Thing objects and the host ThingServer to avoid dependencies there. This would be distinct from datatypes intended for use by people implementing Thing subclasses. Thinking about it, actually some of these types might be useful for Thing implementers, so perhaps a single types module is best. We can always make some types _-prefixed or add an __all__ if we want to mark them as private.
• Datatypes like the current NDArray implementation also belong in a types module that's part of the API - but this might be a separate one.

A types module would not have onward dependencies except for type checking, so should be safe to import as the previous modules.

Other code should be grouped by functionality. Top level submodules probably include:

• server perhaps incorporating
  • ActionManager
  • BlobManager
• cli
• client
• thing
• action
• property
• event
• blob (or merge into io
• io containing MJPEGStream, possibly Blob, NDArray
• thing_description
• example_things

dependencies might get added to the relevant modules rather than centralised. Thing related dependencies might go in thing or client.

Review the current package modules and import relationships, especially exceptions, utilities, introspection, types, server, client, thing, action, property, event, blob, io, thing_description, and example_things. Use the issue discussion to agree on module boundaries and dependencies; done means a settled structure plan ready to guide the later rearrangement.