This PR modifies the existing API docs samples to use DartPad so that all of the samples are now interactive apps on the API docs site.

It also removes the restriction for the max width of the description area so that the dartpad region can expand horizontally.

I updated the first paragraph on the API docs to indicate that Flutter is more than just mobile now (same text as the README.md at the top level).

I modified a few of the examples so that they looked nicer, and fit better on the page.

I added the sample description text above each DartPad instance, since that often defines the context of the example.

I removed animations and images when they were redundant with the sample content. There were a few that made sense to keep, so I did.

* reland "Refactors global key duplication detection (#46183)"

This reverts commit d2b66dbf.

* fix test

This reverts commit 340b193f.

* implicit-casts:false in flutter/lib/src/material

* address review comments

This adds a visualDensity attribute to checkbox, radio, icon button, and chip.

* Update project.pbxproj files to say Flutter rather than Chromium

Also, the templates now have an empty organization so that we don't cause people to give their apps a Flutter copyright.

* Update the copyright notice checker to require a standard notice on all files

* Update copyrights on Dart files. (This was a mechanical commit.)

* Fix weird license headers on Dart files that deviate from our conventions; relicense Shrine.

Some were already marked "The Flutter Authors", not clear why. Their
dates have been normalized. Some were missing the blank line after the
license. Some were randomly different in trivial ways for no apparent
reason (e.g. missing the trailing period).

* Clean up the copyrights in non-Dart files. (Manual edits.)

Also, make sure templates don't have copyrights.

* Fix some more ORGANIZATIONNAMEs

Revert "[Chip] Make sure InkResponse is in the foreground on delete for chips with background color (#41463)" (#43391)

This reverts commit 588275e1.

[Chip] Make sure InkResponse is in the foreground on delete for chips with background color (#41463)

* Make sure InkResponse is visible on delete for chips with background color set

* Override computeDistanceToActualBaseline in layout builder

* Fixed chip ripple.

* Fixed chip ripple. All tests passed.

* Fix one minor detail.

* Fixed reference box.

* Playing around 2.

* Added tests for chip ripple.

* Reverting print-debugging statements

* Remove extra blank line.

* Fixed chip ripple.

* Remove commented code.

* Reconciles with upstream/master.

* Remove print-debugging statement.

* Remove empty line.

* Edit comments.

* Edit style and comments.

* Edit style.

* Fix style and capitalization.

* Return bool.

* Edit style.

* Use getMaterialBox instead of Material.of(...).

* Experiment 3.

* Revert.

* Using tester.pump instead of pumpFrames

* Delete pumpFrames.

* Edit comments.

This attempts to reland #40186 and #41220, that were reverted in #41945.

The main modifications from the original PRs are that I predefine the shortcuts and actions maps instead of defining them inline in the build function, and I use a new mapEquals to do a deep comparison so that we don't rebuild modified things if the contents of the map haven't changed.

I also eliminated an operator== and hashCode that were defined on the Actions widget, since widgets shouldn't have those. (it's too bad though: I get an 85% speedup if we leave this in! Too bad it prevents rebuilding of the children...)

Fixes #40101

Adds an ActivateAction to controls that use InkWell. Make InkWell host the Focus for those controls, and add the top level binding to the ENTER key. This will make it possible to trigger a button using the enter key, and to get an ink response when the button is triggered.

This is a breaking change because it moves the Focus widget into the InkWell. If you have a component that uses the InkWell directly and you used to wrap that InkWell in a Focus widget to give it its notion of focus, it will now not look for that Focus ancestor for its focus state anymore. In order to control focus on the InkWell, you need to give it a FocusNode directly, via the new focusNode parameter. This should not affect users of widgets like OutlineButton or FloatingActionButton and the like, since those have been modified in this PR.

Add the option to configure a chip check mark color

* Create 'center' template

This changes the behavior of text fields, Material buttons, and Chips so that if they are disabled they lose focus. Before this change, it was possible to disable a control and then use focus traversal to reach it anyhow, and in the case of text fields, enter text into a disabled field.

Fixes #33985

I noticed that we were pretty inconsistent with the way that we checked the value of clipBehavior in the framework, so I normalized the usages and updated docs where necessary.

This is a breaking change if you used to pass null explicitly to FlatButton, OutlineButton or RaisedButton constructors, expecting to get Clip.none. It will now assert if you do that. Existing implementations that pass null implicitly by not specifying clipBehavior won't need to change their call sites. It always implicitly defaulted to Clip.none before, and it will continue to do that, it's only places where it was explicitly set to null in order to get the implicit default that it will fail.

Add an autofocus parameter to widgets which use Focus widget internally, and update related docs.

This will allow developers to request that a particular widget be automatically focused when shown.

(Breaking Change) Move some hardcoded pixel values to reusable constants.

* Chip keeps track of state, resolves text color

* Add horizontal padding and properly constrain chip label calculations

* Added regression test for avatar, label and delete icon constraint

Fixes https://github.com/flutter/flutter/issues/21232

Fix the spelling errors in the dartdocs for the framework.

There are no functionality changes here, just documentation fixes.

[Material] Add ability to set shadow color and selected shadow color for chips and for chip themes (#28163)

* Add ability to set shadow color for chips and for chip themes

* Add selected shadow color as a property as well

* Update phrasing of documentation

* Address PR feedback

This converts all remaining "## Sample code" segments into snippets, and fixes
the snippet generator to handle multiple snippets in the same dartdoc block
properly.

I also generated, compiled, and ran each of the existing application samples,
and fixed them up to be more useful and/or just run without errors.

This PR fixes these problems with examples:

1. Switching tabs in a snippet now works if there is more than one snippet in
   a single dartdoc block.
2. Generation of snippet code now works if there is more than one snippet.
3. Contrast of text and links in the code sample block has been improved to
   recommended levels.
4. Added five new snippet templates, including a "freeform" template to make
   it possible to show examples that need to change the app instantiation.
5. Fixed several examples to run properly, a couple by adding the "Scaffold"
   widget to the template, a couple by just fixing their code.
6. Fixed visual look of some of the samples when they run by placing many
   samples inside of a Scaffold.
7. In order to make it easier to run locally, changed the sample analyzer to
   remove the contents of the supplied temp directory before running, since
   having files that hang around is problematic (only a problem when running
   locally with the `--temp` argument).
8. Added a `SampleCheckerException` class, and handle sample checking
   exceptions more gracefully.
9. Deprecated the old "## Sample code" designation, and added enforcement for
   the deprecation.
10. Removed unnecessary `new` from templates (although they never appeared in
   the samples thanks to dartfmt, but still).

Fixes #26398
Fixes #27411

This adds support for logical and physical key information inside of RawKeyEvent. This allows developers to differentiate keys in a platform-agnostic way. They are able to tell the physical location of a key (PhysicalKeyboardKey) and a logical meaning of the key (LogicalKeyboardKey), as well as get notified of the character generated by the keypress. All of which is useful for handling keyboard shortcuts.

This PR builds on the previous PR (#27620) which generated the key code mappings and definitions.