DASH-1272 Allow registered data sources to gate picker visibility by context

[stefanscholz]

Summary

Adds a small, generic extension point to the block_dash data-source registry: a registering plugin can now hide one of its data sources from the block builder's "choose feature" picker based on the editing context, without block_dash needing to know anything about that plugin's rules.

This is the block_dash half of a cross-repo change. The first (and currently only) consumer is dashaddon_repository, which uses it to enforce a new per-preset "block builder" role audience — i.e. who may select a repository preset when adding a Dash block, decided by the user's roles in the context where the block is being added.

What changed

• data_source_factory::is_visible_in_context($identifier, $context) — new helper. If a registry entry carries an optional 'visible' => callable($identifier, $context): bool, it is invoked and its result returned. Entries without a visible callback are always visible, so every existing data source and widget is unaffected.
• edit_form::dash_features_list() — the datasource and widget picker loops now additionally check is_visible_in_context($id, $context) alongside the existing block_dash_visible_addons($id) check, so a gated entry is omitted for users the callback rejects.

Design notes for review

• Generic, not repository-specific. block_dash gains only the concept of "ask the entry whether it's visible here." All role/audience logic lives in the consuming plugin's callback. Nothing references dashaddon_repository.
• Authoring-time only. The gate is applied in the picker (and is intended to pair with save-time validation in the consumer). build_data_source() and the render path are deliberately not gated, so blocks that already reference a now-restricted data source keep rendering for all viewers. No existing block changes behaviour.
• Opt-in / backwards-compatible. The visible key is optional; absence = visible. Core data sources, widgets and other addons are untouched.
• Context source. $context is the block's context, already available in dash_features_list() and already used for the surrounding capability checks (block/dash:managedatasource / managewidget).

Companion change

dashaddon_repository (committed to its dev branch) registers each preset with 'visible' => [repository_factory::class, 'is_selectable'], which resolves the preset's add_roles audience against the editing context. Without this block_dash PR, that callback is simply ignored and presets show unconditionally (i.e. today's behaviour), so the two can merge independently.

Testing

• php -l clean on both changed files; no lines over 132 chars.
• Not in production anywhere yet; verified manually that the picker hides repository presets whose builder audience excludes the current user and shows them to admins / matching roles.
• No block_dash unit tests exercise dash_features_list() picker contents; happy to add coverage if preferred.