[lint] Merge impeller .clang-tidy into main config

[cbracken]

Merges most (but not all) of the impeller .clang-tidy rules into the
main .clang-tidy config. Merges:

• readability-identifier-naming.PrivateMemberSuffix (_)
• readability-identifier-naming.EnumConstantPrefix (k)
• modernize-use-default-member-init.UseAssignment

Does not merge:

• readability-identifier-naming.PublicMethodCase (CamelCase)
• readability-identifier-naming.PrivateMethodCase (CamelCase)

These last two are not merged due to the non-trivial number of existing
field accessors that use field_name() methods to directly return
field_name_. While these are permitted by the C++ style guide, we may
want to move to a single, simple rule and name everything in CamelCase.
These can be enabled in a followup patch.

No new tests added, since this change is style-only.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on
  writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[cbracken]

This change is organised into a stack of commits, one per option, for ease of review.

[cbracken]

@chinmaygarde added three more commits to fix up the last of the issues raised in the presubmit. The first two are non-controversial. I've added some notes to the last commit description; whether we delete the dead store or ignore it is really up to the author's intent with leaving it there.

[cbracken]

It's interesting that it seems to be upset about the local result from Parser::parse getting captured by the local parser in Environment::parse during a chained return. It looks like the only thing captured by the template is a copy of the input string.

I could tack in a // NOLINTNEXTLINE(clang-analyzer-core.StackAddressEscape) above our call to Environment::parse but to be honest I haven't yet completely convinced myself there's no issue here.

The stack of calls looks something like:

• Reflector::InflateTemplate(std::string_view&) (unrelated but this should probably just be std::string_view, not a ref; sent Pass std::string_view by value not by ref #33699)
• Environment::render(std::string_view, const json&)
• Environment::parse(std::string_view)
• Parser::parse(std::string_view)
• Parser::parse(std::string_view, std::string_view)
• Template::Template(const std::string&)

[cbracken]

Hrm. Can't find an easy way to work around the clang-analyzer-core.StackAddressEscape issue since it's in a header library. I did try jamming a NOLINTBEGIN/NOLINTEND pair around the #include as a desperate measure, but didn't work :/

Any thoughts?

[zanderso]

@chinmaygarde wants to take a look at the underlying issue in inja.

[cbracken]

SGTM! On the surface it looks sane but there's also enough parameters passed to locals, then returned that, as I say, I haven't yet completely convinced myself there's no issue there.

[chinmaygarde]

I haven't had the chance to take a look at the Inja issue. Frankly, this escaped my attention. Filed flutter/flutter#105732 and assigned to myself. Marking this WIP in the meantime. Will continue with this after the linked issue is fixed.

[chinmaygarde]

@cbracken I won't be able to get to this before the end of the month realistically. Are you blocked on this? Since there is an issue filed for it already, maybe you can proceed with the NOLINT?

[cbracken]

Not blocked on this; but I'll add the nolint to land it before I forget. Thanks.

[skia-gold]

Gold has detected about 2 new digest(s) on patchset 14.
View them at https://flutter-engine-gold.skia.org/cl/github/33692

[cbracken]

@chinmaygarde to re-check 2e33201 which is a non-stylistic change, but rather prevents use-after-move warnings int the test expectations below.

Broke out into #34197