CmdPal: Load pinned command items from anywhere (#45566)

This doesn't actually have a UX to expose this yet - we need to stack a
couple of PRs up to get to that.

But this adds plumbing such that we can now stash away a command ID, and
retrieve it later as a top-level command. Kinda like pinning for apps,
but for _anything_.

It works off of a new command provider interface `ICommandProvider4`,
which lets us look up Command**Item**s by ID. If we see a command ID
stored in that command provider's settings, we will try to look it up,
and then load it from the command provider.

e.g.

```json
    "com.microsoft.cmdpal.builtin.system": {
      "IsEnabled": true,
      "FallbackCommands": {
        "com.microsoft.cmdpal.builtin.system.fallback": {
          "IsEnabled": true,
          "IncludeInGlobalResults": true
        }
      },
      "PinnedCommandIds": [
        "com.microsoft.cmdpal.builtin.system.lock",
        "com.microsoft.cmdpal.builtin.system.restart_shell"
      ]
    },
```
will get us
<img width="840" height="197" alt="image"
src="https://github.com/user-attachments/assets/9ed19003-8361-4318-8dc9-055414456a51"
/>

Then it's just a matter of plumbing the command provider ID through the
layers, so that the command item knows who it is from. We'll need that
later for actually wiring this to the command's context menu.

related to #45191 
related to #45201

src/modules/cmdpal/doc/initial-sdk-spec/initial-sdk-spec.md

@@ -77,6 +77,7 @@ functionality.
     - [Rendering of ICommandItems in Lists and Menus](#rendering-of-icommanditems-in-lists-and-menus)
   - [Addenda I: API additions (ICommandProvider2)](#addenda-i-api-additions-icommandprovider2)
   - [Addenda IV: Dock bands](#addenda-iv-dock-bands)
+    - [Pinning nested commands to the dock (and top level)](#pinning-nested-commands-to-the-dock-and-top-level)
   - [Class diagram](#class-diagram)
   - [Future considerations](#future-considerations)
     - [Arbitrary parameters and arguments](#arbitrary-parameters-and-arguments)
@@ -2128,6 +2129,36 @@ Users may choose to have:
   - Dock bands will still display the `Title` & `Subtitle` of each item in the
     band as the tooltip on those items, even when the "labels" are hidden. 
 
+### Pinning nested commands to the dock (and top level)
+
+We'll use another command provider method to allow the host to ask extensions
+for items based on their ID.
+
+```csharp
+interface ICommandProvider4 requires ICommandProvider3
+{
+    ICommandItem GetCommandItem(String id);
+};
+```
+
+This will allow users to pin not just top-level commands, but also nested
+commands which have an ID. The host can store that ID away, and then later ask
+the extension for the `ICommandItem` with that ID, to get the full details of
+the command to pin.
+
+This is needed separate from the `GetCommand` method on `ICommandProvider`,
+because that method is was designed for two main purposes:
+
+* Short-circuiting the loading of top-level commands for frozen extensions. In
+  that case, DevPal would only need to look up the actual `ICommand` to perform
+  it. It wouldn't need the full `ICommandItem` with all the details.
+* Allowing invokable commands to navigate using the GoToPageArgs. In that case,
+  DevPal would only need the `ICommand` to perform the navigation.
+
+In neither of those scenarios was the full "display" of the item needed. In
+pinning scenarios, however, we need everything that the user would see in the UI
+for that item, which is all in the `ICommandItem`.
+
 ## Class diagram
 
 This is a diagram attempting to show the relationships between the various types we've defined for the SDK. Some elements are omitted for clarity. (Notably, `IconData` and `IPropChanged`, which are used in many places.)