Add a design-time extensibility point for control text baseline snap lines

## Problem

WinForms designer baseline snap lines are calculated centrally by `DesignerUtils.GetTextBaseline` from the control client rectangle, font metrics, and alignment. Built-in designers then add hard-coded offsets for border/style differences (for example `TextBoxBaseDesigner`, `ButtonBaseDesigner`, `ComboBoxDesigner`, and `UpDownBaseDesigner`).

Controls whose rendered text baseline is shifted by internal chrome or non-client layout cannot provide that offset themselves. This is visible with the proposed .NET 11 `VisualStylesMode` TextBox rendering: the designer guideline crosses the text instead of aligning with its baseline because the runtime control reserves additional non-client/chrome space.

A custom designer can override the complete virtual `ControlDesigner.SnapLines` collection, but there is no narrow control-level extensibility point for supplying only a baseline offset. Replacing the full collection duplicates designer behavior and is not suitable for reusable control infrastructure.

## Proposed direction

Introduce an **internal** control-to-designer baseline-offset provider first. The common designer baseline path would query the provider and apply its offset after calculating the normal font/alignment baseline. Design the internal contract so it could later become an interface or reviewed public API without changing its semantics.

The exact contract is open for design; conceptually it should let a control provide a DPI-aware offset for its effective rendering mode without exposing `DesignerUtils` or requiring the control to construct `SnapLine` objects.

## Acceptance criteria

- Preserve existing baseline values for TextBox, CheckBox, RadioButton, Button, Label, ComboBox, DateTimePicker, and UpDown controls.
- Allow a control to contribute a baseline offset without replacing the complete `SnapLines` collection.
- Account for font, DPI, alignment, border style, internal chrome/padding, `FlatStyle`, and `Appearance` where applicable.
- Add direct baseline tests for TextBox and CheckBox/RadioButton scenarios rather than only asserting snap-line counts.
- Keep the first implementation internal; any public interface requires normal API review.

## Relevant code

- `System.Windows.Forms.Design/DesignerUtils.GetTextBaseline`
- `TextBoxBaseDesigner.SnapLines`
- `ButtonBaseDesigner.SnapLines`
- `UpDownBaseDesigner.SnapLines`
- `ControlDesigner.SnapLines`

## Reproduction

Place a TextBox using the proposed .NET 11 visual styles next to another text-bearing control in the WinForms designer. The horizontal baseline guide is calculated from the legacy client/border offsets and crosses the TextBox glyphs instead of following their rendered baseline.

Start with DesignerUtils.GetTextBaseline and the SnapLines implementations in TextBoxBaseDesigner, ButtonBaseDesigner, UpDownBaseDesigner, and ControlDesigner. Review the existing baseline behavior and direct tests, then define the internal offset contract and verify unchanged baselines for the listed controls plus direct TextBox and CheckBox/RadioButton scenarios across the stated rendering factors.

Written by the indexing model from the issue text.