RFC7396 interacts oddly with Thing Connections

Thing Slots (introduced in #185 ) may treat a configuration key that is None differently to one that is missing. For example:

import labthings_fastapi as lt

class MyOtherThing(lt.Thing):
    ...

class Example(lt.Thing):
    myslot: MyOtherThing | None = lt.thing_slot()

If we configure the Example Thing to set the slot to None it will evaluate to None at runtime, while if it's left blank it may return an instance of MyOtherThing if one is available.

There are some edge cases where patching a configuration as per RFC7396 (see #189 ) could lead to a confusing situation in which one behaviour is expected and the other is observed, because it uses null (i.e. None) to signal that a property should be deleted.

The simplest resolution here might be to introduce a value that may be used instead of None when required. Possibly False would be appropriate. There would still be the potential for confusion, but at least there would be an obvious fix. I guess we could also just avoid using None, but it does feel like the right Python value to use, as it's what gets returned by the slot.

This would only occur where a configuration is being patched to disable a connection on a Thing. That is, I think, something of an edge case and so this is not a high priority.

Start by reviewing the Thing Slots behavior introduced in #185 and the RFC7396 patching discussion in #189. Reproduce the difference between a missing slot configuration and an explicit None value, then determine and document an unambiguous behavior for disabling a connection during configuration patches.