[ffigen] Config update part 3: renaming visitor

[liamappelbe]

Add the Visitor infra. So far only the renaming logic is ported to visitors, since it's the simplest to port.

Related: #2062, #2770, #2830

[github-actions]

Package publishing

If you have publishing permissions, you can use the links below to publish the changes after merging this PR.

Package	Version	Status	Publish tag (post-merge)
package:code_assets	1.3.0-wip	WIP (no publish necessary)
package:data_assets	0.20.0	already published at pub.dev
package:ffi	2.2.0	already published at pub.dev
package:hooks	2.2.0-wip	WIP (no publish necessary)
package:hooks_runner	1.6.2-wip	WIP (no publish necessary)
package:jni_flutter	1.0.2	already published at pub.dev
package:jni_util	1.0.0	already published at pub.dev
package:native_toolchain_c	0.19.4-wip	WIP (no publish necessary)
package:record_use	1.1.0	ready to publish	record_use-v1.1.0
package:swift2objc	0.3.0-wip	WIP (no publish necessary)
package:swiftgen	0.1.3	already published at pub.dev

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[github-actions]

PR Health

Breaking changes ✔️

Package	Change	Current Version	New Version	Needed Version	Looking good?

This check can be disabled by tagging the PR with skip-breaking-check.

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

This check can be disabled by tagging the PR with skip-changelog-check.

API leaks ✔️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbol	Leaking sources

This check can be disabled by tagging the PR with skip-leaking-check.

[dcharkes]

LGTM

Small nit: Write a general PR description. E.g. We introduce support for renaming in the visitors and all existing renaming logic is pulled out into visitors as an internal implementation strategy.

Also, state that we don't do conflict resolution in a visitor currently. Do we do name conflict resolution before or after the user-defined renames? I suppose we don't change the semantics of in which order we do it. But we should make sure we do something similar for JNIgen and FFIgen and document in the doc comments what happens.

• Conflict resolution before user-defined renames: then conflicting user-renames lead to error messages failing code gen
• User-defined renames before conflict-resolution-renames: then we should emit warnings that a rename happened and might have voided user intend.

[dcharkes]

what are these references to oldName. They are not original name. What does old mean in this context?

[dcharkes]

Would benefit from the examples you have on the visitors doc comment already.

(I imagine users would look at the doc comment of the visitor base class more often than the visitors field.)

[dcharkes]

Add a small example snippet in the doc comment.

[dcharkes]

nit: inline the visitor instead

[goderbauer]

LGTM