consider migrating some lints to analyzer diagnostics (hints, warnings)

[pq]

The line between lints and hints has always been a little fuzzy but over time some lints have proven uniformly useful or uncontroversial enough that we should consider "graduating" them to analyzer hints or warnings. This is particularly true of any lints that might be considered as sensible defaults (as in the canonical lints discussion: #2409).

(Update 1/20: scoring lints added with notes.)

rule	notes
avoid_empty_else	hint (dead code)
avoid_relative_lib_imports
avoid_shadowing_type_parameters
avoid_types_as_parameter_names
await_only_futures
camel_case_extensions
camel_case_types
curly_braces_in_flow_control_structures
empty_catches
file_names
hash_and_equals
iterable_contains_unrelated_type	warning
list_remove_unrelated_type	warning
no_duplicate_case_values	warning?
non_constant_identifier_names
package_prefixed_library_names
prefer_generic_function_type_aliases
prefer_is_empty
prefer_is_not_empty
prefer_iterable_whereType
prefer_typing_uninitialized_variables
provide_deprecation_message
unawaited_futures
unnecessary_overrides	hint
unrelated_type_equality_checks
valid_regexps	hint?
void_checks	hint

Related: #1179

/cc @munificent @mit-mit @natebosch @jakemac53 @bwilkerson

[devoncarew]

I'm curious if the diagnostics would share the same error codes as the previous lints? If this would be a mostly transparent change for users, modulo some analysis issues just being on by default?

[bwilkerson]

If the codes were the same, then yes, it would be mostly transparent for anyone that previously had the lint enabled. So, yes, we should try to preserve the code.

[pq]

@bwilkerson and I took a quick look at the scoring lints and identified a few candidates for promotion.

Feedback welcome!

/fyi @scheglov