* Added support for surfaceTintColor and shadowColor to the Dialog widgets.
* Updated the defaults for Material.shadowColor and Material.surfaceTint to allow turning off the features with a transparent color.
* Added support for shadowColor and surfaceTintColor for Drawer widget.

This reverts commit 79013b2b.

* Revert "Revert "Set `IconButton.visualDensity` default to `VisualDensity.standard` (#109349)" (#109421)"
Co-authored-by: Qun Cheng <quncheng@google.com>

This reverts commit 3070baf1.

* Set IconButton's visualDensity to standard
Co-authored-by: Qun Cheng <quncheng@google.com>

* Created IconButtonTheme and apply it to IconButton

* Added standard IconButton for M3 with new ButtonStyle field

* Added IconButton examples for standard, filled, filled_tonal, and outlined types
Co-authored-by: Qun Cheng <quncheng@google.com>

This reverts commit 5fd259be.

This reverts commit d056500b.

This reverts commit 31de052e.

This reverts commit e2490f29.

Just converting some test files to NNBD

* add language version 2.8 in packages/flutter

* enable non-nullable analyzer flag

* Adds default cursor and/or mouseCursor property to a number of widgets.
* Adds `MaterialStateMouseCurrsor`.

This adds a new navigationMode to the MediaQueryData that indicates how focusable controls should behave under different navigation modes, currently with two modes: NavigationMode.traditional, and NavigationMode.directional.

It may seem like focusing a disabled control is not desirable, but this is useful for user interfaces that use DPAD navigation because if a control gets disabled, losing focus is disruptive to the user, and it is difficult to control where the focus will end up unless it is done explicitly.

This re-lands #49235 with the addition of includeSemantics flag on the Focus widget so that the FocusTraversalGroup can create a Focus widget without affecting the semantics tree.

The FocusTraversalGroup uses the Focus widget to create a grouping of descendants for traversal, but doesn't actually participate in focus (canRequestFocus is always false), so we don't want it to add a Semantics widget in that case, since that can cause semantics changes. The canRequestFocus attribute can also be used when a widget is disabled, so we do sometimes want to include Semantics even if that is false, but not in the case where it is always false, as for FocusTraversalGroup.

- Added a test to make sure that FocusTraversalGroup doesn't add any semantics information.

This reverts commit 8ef5e2f0 because it breaks some semantics tests.

This change adds a way to provide explicit focus order for a part of the widget tree.

It adds FocusTraversalPolicyGroup, which in many ways is similar to DefaultFocusTraversal, except that it groups a widget subtree together so that those nodes are traversed as a group. DefaultFocusTraversal doesn't work as one would expect: If there is more than one DefaultFocusTraversal inside of a focus scope, the policy can change depending on which node was asked to move "next", which can cause unexpected behavior. The new grouping mechanism doesn't have that problem. I deprecate DefaultFocusTraversal in this PR.

It also adds OrderedFocusTraversalPolicy, which is a policy that can be supplied to FocusTraversalPolicyGroup to set the policy for a sub-tree. It looks for FocusTraversalOrder inherited widgets, which use a FocusOrder to do the sorting. FocusOrder has two subclasses: NumericalFocusOrder (which sorts based on a double), and LexicalFocusOrder, which sorts based on a String.

As part of doing this, I refactored the way FocusTraversalPolicy is implemented so that it has more default implementation methods, and exposes a new protected member: sortDescendants, which makes it easier for developers to make their own policy subclasses: they only need to implement sortDescendants to get a new ordering behavior, but can also still override any of the default implementation behaviors if they need different behavior.

I was able to do this without breaking the API (AFAICT).