Improve handling of Kotlin versioning

[stuartmorgan]

(See #78792 for background, with bluefireteam/audioplayers#714 (comment) as an example of the pain point)

Our create template is apparently using a fairly old version of Kotlin, and it appears that there are issues if plugin developers attempt to use a newer version. Some things we should consider:

• Updating the templates to a newer version (only fixes new apps)
• Warning (or migrating, if that's backwards compatible; I'm not familiar with the specifics of Kotlin versioning behaviors) for apps with old Kotlin versions.

However, we'll still have this a general problem going forward, so we should figure out how we're going to handle that. /cc @blasten as #59037 (comment) sounds like a potential solution here. If each plugin can choose its version of Kotlin without conflicting with other plugins and/or the app, that would be ideal. Failing that we'll likely need an ongoing communication and migration strategy so that plugin developers a) know what version is safe to use, and b) can regularly get that version moved forward if possible.

[larssn]

@stuartmorgan But luanpotter commented that the fix was to upgrade to 1.4, as it has trailing commas. If Flutter defaulted to the newest version of kotlin, users wouldn't be having these issues in the first place. So as I see it, the pain point is you guys NOT upgrading to kotlin 1.4.

Also, upgrading the kotlin version is super easy, and something most people should be able to figure out. Another option is to update the tooling, to automatically update kotlin on behalf of the user.

[stuartmorgan]

If Flutter defaulted to the newest version of kotlin, users wouldn't be having these issues in the first place.

Please refer to the last paragraph in the issue description. This is a general problem; 1.4 is not going to be the last time something is added to Kotlin.

Also, upgrading the kotlin version is super easy, and something most people should be able to figure out.

The existence of issues like the one linked above is evidence that just leaving it up to everyone to manage their own Kotlin version without tooling assistance isn't a great approach. If it were trivial for everyone to just do this themselves, it wouldn't really matter what version the template used.

Another option is to update the tooling, to automatically update kotlin on behalf of the user.

That's mentioned above. There are potential issues with code that is broken by updates however; backwards compatibility is not guaranteed.