Add resource_family for grouping resource types in the segmentation

[espenbodal]

Closes #106. Adds resource_family(p::Resource), defaulting to typeof(p), and uses it in res_types and res_types_vec. No behaviour change for existing resources; see the issue for the motivation. Includes tests, NEWS entry and documentation.

[Copilot]

🟡 Changes recommended

The public API page references an unexported function without qualification, which can break documentation generation.

1 open finding

• Unqualified resource_family breaks Documenter docs build · New

What changed in this PR

Adds resource-family grouping so related resource types can share segmentation and resource-specific model hooks.

Changes:

• Adds resource_family and updates segmentation.
• Adds integration tests.
• Documents the extension API and release note.

File	Description
src/​structures/​resource.jl	Implements family-based segmentation.
test/​test_resource.jl	Tests grouping and model-hook invocation.
docs/​src/​library/​public/​resources.md	Adds API documentation.
docs/​src/​how-to/​extend-resource-functionality.md	Explains family extension usage.
NEWS.md	Records the new API.

🧠 Review effort: Balanced

---

Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.

[JulStraus]

See my comments. Note that the current module suggestion from Copilot is bullshit. That is not the structure we want to have. If a function is not exported, it is not in the external library, that is the simple rule.

Additional comment:
We are currently in a situation with additional variables that it always only create one set of variables per resource, even if it theoretically could get them from a higher hierarchy as we use it for Nodes, Links, or ExtensionData. Do we see a case where this is not sufficient?

I.e., for your example,

abstract type AbstractPotentialPower <: Resource end
struct PotentialPower <: AbstractPotentialPower
    # fields as above
end
struct BoundedPotentialPower <: AbstractPotentialPower
    # fields with different bounds
end

you can either create variables for PotentialPower and BoundedPotentialPower (if you do not add the new method) or AbstractPotentialPower. But never variables for PotentialPower and AbstractPotentialPower simultaneously. In this case, we must follow the approach used for, e.g., Node.

[JulStraus]

Put it under the header Extension functions in the internal library. My plan is to clean up a bit in the internal library and that is something users should extend. You can also remove the text around it as it is explained in the documentation.

Or do you foresee that this function should be used directly in other packages? I honestly do not see the requirement yet.