Add dummy preference descriptions to open AI config widget

[colin-grant-work]

What it does

Fixes #15160 by adding preferences whose descriptions redirect users to the config widget to enable them to perform more advanced AI configuration.

How to test

1. Open the settings and look for settings under 'AI Features ... Agents', 'AI Features ... Models', and 'AI Features ... Prompt Templates'
2. You will find a dummy preference with a link to open the configuration widget.
3. Click the link, and the config widget should open.

The third segment (details) is to work around #15165

Follow-ups

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[sdirix]

It fulfills the purpose but I'm not so happy about the result as the "Edit in settings.json" is wildly misleading.

We might need to register a custom preference render to avoid producing it.

And if we're doing that, we could instead have a custom renderer for these sections and within there render the hint. This would allow us to avoid declaring a non-existing preference.

Generally speaking, supporting a description text for sections would be nice but might be out of scope for this issue.

[colin-grant-work]

Generally speaking, supporting a description text for sections would be nice but might be out of scope for this issue.

I had the same thought. One easy workaround would be a special renderer for preferences with declared type null that just doesn't have any interactable at all.

[colin-grant-work]

I've pushed a commit that adds a renderer for preferences whose only declared type is null and confirmed that that includes only the three that I've added here so that only the message appears.

[sdirix]

I'm a bit torn because it works, however in the end it's still a hack.

It's a hack because we have many unintended side effects:

• we register preferences although there are none
• we offer these preferences in the JSON Editor for autocomplete etc.
• we offer UI to copy the preferences name, id, etc. although they are useless
• they influence search in the preferences UI

Of course the overall impact is minimal, and I also don't see any collateral as I can't think of a real world use case for preferences of type null.

---

Overall it would be much nicer to enrich sections to allow optional descriptions. Then we could add this text to these sections and avoid registering additional preferences.

---

However I don't want to block the merge if we want to tackle this in a follow up then

[sdirix]

Suggested change

	// Copyright (C) 2025 Eclipse GmbH and others.
	// Copyright (C) 2025 EclipseSource GmbH and others.