Consider new lints for inclusion v3.9.0-3.11.0

[natebosch]

New lints:

• simplify_variable_pattern
• remove_deprecations_in_breaking_versions
• switch_on_type
• unnecessary_unawaited

I think we can start with a single issue to cover all 4 and if initial votes are aligned we can skip detailed discussion. We can fork an issue for anything which isn't aligned to start.

[natebosch]

lint	vote	comment
simplify_variable_pattern	recommended	style, but no reason not to follow this
remove_deprecations_in_breaking_versions	recommended	occasionally worth breaking, but always worth checking
switch_on_type	core	may prevent bugs, no reason to violate this
unnecessary_unawaited	recommended	style. There could be an argument against this, but our recommended style should default to avoiding redundancy

[lrhn]

lint	vote	comment
simplify_variable_pattern	recommended	Strict improvement for code - use the more specific and precise language feature. (There is a typo in the BAD example.)
remove_deprecations_in_breaking_versions	none	Don't think it's something we should be forcing. It's a nice lint if you want it, but you can always introduce it yourself. There will be false positives, and no way out if it other than an // ignore:. Or using 1.0.1 as the first releases. Too far from being a Dart lint, this is a process decission. The Dart team are not in charge of other people's processes.
switch_on_type	recommended	Needs better docs! Is the problem that the switch (e) expresson is a Type, or that it's e.runtimeType precisely, or that the case e: expression is a type literal? Will it trigger if I do switch (o as Object) { case int: ...., case 42: ... }? The documentation should describe precisely when it will and won't trigger. Other than that, I'm for anything that makes people not work with Type objects, so ship it! (After updating docs.)
unnecessary_unawaited	recommended (or not at all)	Meh. The unawaited is unnecessary, so by all means tell people that it is, but it's not harmful to have the unawaited. (I never use unawaited anyway, so I'm probably not the target audience.) But why is this a separate lint, and not just part of the lints that otherwise require unawaited? You'd never enable this lint if you don't have unawaited_futures or the synchronous sibling lint enabled already. Why not just make those also say when they don't require an unawaited?