Introduce Widget.label and treat name as alias

[philippjfr]

First part of migration plan towards panel-material-ui widgets.

[Copilot]

Pull request overview

This PR introduces Widget.label as the new primary parameter for widget labels, treating name as a deprecated alias for backward compatibility. This is the first step in a migration plan towards panel-material-ui widgets.

Key Changes:

• Added label parameter to the base Widget class with deprecation warnings for name
• Updated all widget factory functions to use label instead of name parameters
• Updated _rename mappings across all widget classes to map label instead of name

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
panel/widgets/base.py	Introduces label parameter, adds deprecation logic for name, and implements sync methods between the two parameters
panel/widgets/widget.py	Updates widget factory function signatures and implementations to use label instead of name
panel/widgets/texteditor.py	Updates _rename mapping from 'name': 'name' to 'label': 'name'
panel/widgets/terminal.py	Updates _rename mapping to exclude 'label' instead of 'name'
panel/widgets/tables.py	Updates _rename mapping and download_menu method to use label, plus unrelated bundled_module_string changes
panel/widgets/speech_to_text.py	Updates _rename mapping to exclude 'label' instead of 'name'
panel/widgets/select.py	Updates _rename mappings in AutocompleteInput, _RadioGroupBase, and _CheckGroupBase
panel/widgets/misc.py	Updates _rename mappings and documentation examples to use label
panel/widgets/input.py	Updates _rename mappings and internal references from name to label
panel/widgets/indicators.py	Updates _rename mappings, documentation examples, and internal references throughout various indicator widgets
panel/widgets/icon.py	Updates _rename mappings in _ClickableIcon and ButtonIcon classes

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[maximlt]

In HEP2, there's a suggestion to start by emitting a PendingDeprecationWarning for deprecations that have the potential to be extremely noisy. And then upgrade it to DeprecationWarning, and finally to FutureWarning (as e.g. notebook users would never see PendingDeprecationWarning/DeprecationWarning).