Focus management improvements to ContentDialog

[Koichi-Kobayashi]

Pull request type

• Update
• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes

What is the current behavior?

• Even when displaying the ContentDialog, focus does not shift to the ContentDialog buttons.
• Cannot close with the Esc key (though it closes if focus shifts...)

Issue Number: #1585

What is the new behavior?

• Add button names (PART_ContentDialogPrimaryButton, PART_ContentDialogSecondaryButton, PART_ContentDialogCloseButton) to XAML template
• Add Focusable and IsTabStop properties to buttons in XAML template
• Implement SetFocusToFirstAvailableButton method with checkIsFocused parameter
• Set focus early in OnLoaded/OnApplyTemplate without validation
• Validate focus state using Dispatcher.BeginInvoke in OnLoaded to respect developer logic
• Skip focus setting if already on button or non-button control
• Auto-focus primaryButton when focus is on ContentDialog or nowhere
• Add helper methods IsButtonAvailableForFocus and TrySetFocusToButton
• Add Gallery samples demonstrating focus management behavior:
  • Three Button ContentDialog (Default Focus: Secondary Button)
  • ContentDialog with Focusable Content (Default Focus: Primary Button)
  • ContentDialog with Icons (Default Focus: Secondary Button)
  • ContentDialog with Auto Focus (Default Focus: Primary Button)

Other information

[Koichi-Kobayashi]

Hello, @apachezy
I also tried fixing the ContentDialog focus issue. What do you think?

[apachezy]

@Koichi-Kobayashi

😅, I've reopened #1601. It's possible that it overlaps with this PR...

[Koichi-Kobayashi]

@apachezy
Oh...
I missed it.

[Koichi-Kobayashi]

I'm withdrawing this as it was a duplicate.

[apachezy]

@Koichi-Kobayashi

I apologize, the discussion I sent you previously was AI-translated and edited, and may be inaccurate or misleading.

The focus priority logic I'm trying to convey is:

1. The first focusable control in the content area (following the Windows App Design Guidelines; in fact, Windows has had this rule for a long time).

2. Then try the default button. Since WPFUI buttons can have their "Appearance" property set to "Danger" or "Caution," try avoiding it.

3. Then try a non-default button that is safe.

4. Fallback logic...

I only used translation software this time, and I hope my expression is accurate enough.