refactor: Add new lint rules

[spydon]

Description

This PR adds the following lint rules to our list:

always_put_required_named_parameters_first
avoid_multiple_declarations_per_line
avoid_positional_boolean_parameters
avoid_returning_null_for_void
avoid_returning_this
avoid_unnecessary_containers
enable_null_safety
library_private_types_in_public_api
no_leading_underscores_for_library_prefixes
no_leading_underscores_for_local_identifiers
prefer_null_aware_method_calls
tighten_type_of_initializing_formals
unnecessary_late
use_setters_to_change_properties

And these rules were considered, and some changes were made according to them as a clean-up, but in many places they didn't make sense (prefer_asserts_with_message I would have included, but there were too many places that needed to be changes):

collection_methods_unrelated_type
prefer_asserts_with_message
avoid_renaming_method_parameters

Checklist

• I have followed the [Contributor Guide] when preparing my PR.
• I have updated/added tests for ALL new/updated/fixed functionality.
• I have updated/added relevant documentation in docs and added dartdoc comments with ///.
• I have updated/added relevant examples in examples or docs.

Breaking Change?

• No, this PR is not a breaking change.

[spydon]

Does this change make sense @ASGAlex? And also, shouldn't keepOldPosition be inverted in the if?

[ASGAlex]

Yes, you are right the both things are bugs.
But I see that function that uses it - hasMoved - is not used anywhere, just mentioned in comments.
Looks like I thought about future optimization here but idea was lost then...
So we have two options here:

1. Fixing mentioned bugs
2. Safely remove unsed functionality.

[spydon]

Alright, sounds like the best option is removing it then.
Would you like to make a PR for removing it? :)

[spydon]

@ASGAlex Hmm, but how can it work if hasMoved isn't used? Shouldn't that be used to determine if new quadrants might need to be created, or does it always check that now?

[luanpotter]

LOVE IT!

[Gustl22]

@spydon Isn't this change breaking in the sense, that linter (flutter analyze) fails for projects, which do upgrade minor versions / patches automatically (like audioplayers)? I'd recommend to release a major version for flame_lint :)

[spydon]

@spydon Isn't this change breaking in the sense, that linter (flutter analyze) fails for projects, which do upgrade minor versions / patches automatically (like audioplayers)? I'd recommend to release a major version for flame_lint :)

For semver, when versions are less than 1.0.0, the users can expect breaking changes. You're right that it is breaking though and should have been marked as such.

[Gustl22]

Alright then :)