Tree View API: allow extensions to control item indentation/icon-twistie alignment (TreeViewOptions.indentation)

### Summary

Custom `TreeView`s currently have no way to control how leaf-item icons align relative to sibling twisties. The built-in file Explorer makes a single, container-wide decision driven by the icon theme:

```ts
container.classList.toggle('align-icons-and-twisties', theme.hasFileIcons && !theme.hasFolderIcons);
```

Custom views can't rely on that assumption because their collapsible items may individually have or lack icons. Any heuristic that infers alignment from sibling analysis (see #307350 and PR #308165) inevitably trades one inconsistency for another: aligning labels in one part of a view can misalign equal-depth items elsewhere in the same view. As discussed at length in #308165, this appears to be a *logical* limitation of inferring a global layout decision from per-item data, not an implementation bug.

### Proposal

Add an explicit opt-in on `TreeViewOptions` so the extension declares the intent:

```ts
export interface TreeViewOptions {
// ...existing options
indentation?: 'explorer' | boolean | undefined;
}
```

- `undefined` — current default behavior (backward compatible)
- `'explorer'` — infer alignment from the active file icon theme exactly as the Explorer does (best for file-system-like trees)
- `boolean` — force icon/twistie alignment on or off, giving a fully consistent, icon-independent layout regardless of theme

(Exact shape — enum vs. mixed union — is open for design discussion; @n-gist suggested an enum may read cleaner.)

### Motivation / context

- Downstream bug: #307350 (sibling items shift when a collapsible item without an icon is added).
- PR #308165 improves the default heuristic but, as its review thread documents, cannot fully satisfy "an item's icon should never affect its siblings" while also matching Explorer behavior — the two goals are mutually exclusive for mixed-icon custom trees.
- @n-gist has done extensive testing (with a reusable test-extension kit) and is willing to stay involved in the API design and validation.

Happy to implement this behind a proposed API (`treeViewIndentation`) if the team is open to the direction. Flagging for guidance on the API shape first, per the proposed-API process.