Validate Thing Descriptions during startup

If a Thing Description can't be generated for a particular Thing, there's not much point starting the server: it would probably be more useful to fail with a meaningful traceback than start up only to fail when a client attempts to use it.

This is particularly important as we support deferred type annotations: the various models and types associated with a Thing (properties, actions, etc.) are not evaluated until they're needed, meaning the server may finish starting up with Things that still have un-evaluated type hints. These may then later fail to be converted to DataSchema instances as needed by the Thing Description.

I think it would be useful to generate a Thing Description during server start-up, to surface these errors early. This isn't an effort-free process and may take a second or two, but I think we'd get more or less all of the benefit from getting to the stage of having at ThingDescription model: we wouldn't actually need to serialise (or validate) the JSON, though we could.

Clearly there would need to be a way to turn this off. I think it shouldn't be that noticeable when starting an HTTP server, but it would be horrible in test code.

I don't know if it would be a good idea to use the config file to specify whether this happens: I think keeping it Python-only would make it easier to skip when needed (in test suites) but benefit from having a sanity check whenever a server starts.

I may also be pessimistic about how long it takes: it could be very quick at which point I'm worrying unduly (though it would still be a good idea to provide an opt-out).

Start by tracing server startup and the existing ThingDescription and DataSchema generation paths. Determine how startup can generate a Thing Description and how a Python-level opt-out should work, including for test code. Done means invalid deferred type annotations fail during startup with a meaningful traceback, while the check can be disabled.