Custom item types based on StartingMaterial or Equipment behave like samples #2204

Following a discussion with @davidwaroquiers:

When a plugin defines a custom item type that subclasses StartingMaterial or Equipment, the new type inherits the fields and the edit page of that built-in type, but it doesn't behave like it:

• it is listed and created from the Samples page, not from Starting Materials / Equipment;
• it is owned by its creator and private, instead of being shared like inventory items (no owner, visible to everyone unless restricted to groups, UNGROUPED_INVENTORY);
• item pickers looking for starting_materials (e.g. synthesis constituents) don't find it.

This happens because listings and permissions are decided from type strings (INVENTORY_TYPES = ("equipment", "starting_materials"), the /starting-materials/ and /equipment/ endpoints, the create dialogs), so a subclass with its own type never matches.

This might be annoying for modelling lab-specific chemicals or instruments as plugin types: they end up mixed with samples and hidden from colleagues who should be able to use them.

Proposal: let a plugin opt in explicitly, with a model-level hint:

class Precursor(StartingMaterial):
    model_config = ConfigDict(json_schema_extra={"datalab_behave_as": "starting_materials"})
    type: Literal["precursors"] = "precursors"

The hint would only be accepted if the model inherits from that built-in type, and types without it would keep today's behaviour.

Related: #2145 ("which custom items should appear in which tables"). The configurable item-table views planned in #2168/#2035 would also cover where such types are listed, but not their permissions or the item pickers, so the two should fit together.

I have a draft implementation that I'll open as a PR referencing this issue.