[FEATURE] Workflow action to populate App Id and App Name to iOS files

[jfmcquade]

What? Follow-up to #2234.

The new iOS config files require an app name (e.g. "PLH Teens") and an app ID (e.g. "international.idems.plh-teens"). These can match the values that are already required for Android builds.

Currently we have the values PLH Teens and international.idems.plh-teens hardcoded in the android build files (as well as the top-level file capacitor.config.ts), and these strings are replaced as part of the reusable-android-build github action.

This could be improved in 2 ways:

1. Use placeholder values (for the iOS files I've used *app_name* and *app_id*)
2. Handle the string replacement with a script, which can be run both locally and as part of a github action
   • Analogous to the version script (see #2206)

I think it would make sense to refactor the existing Android build action when adding support for an iOS implementation. For iOS, the strings exist in the file ios/App/App.xcodeproj/project.pbxproj, I've used the placeholder strings *app_name* and *app_id* as the strings that need to be replaced per deployment.

[chrismclarke]

When working on this it might also make sense to do a little bit of tidying to the android build files. As suggested on mattermost (linked to #2236), I think instead of marking fields to file as *var_name* and override the file it might be better to

1. Use separate template files, e.g. ios/App/App.xcodeproj/project.template.pbxproj that contain placeholder versions. This means we can then add the production file to a gitignore so that local users can still have valid configurations populated to their workspaces.

2. Use a more conventional variable indicator, probably something shell-friendly like ${var_name} as likely these variables will be updated using github actions that will either be executed in node or as shell scripts.

[jfmcquade]

That sounds like a good idea. In which case i think #2238 should be handled after this issue, or possibly included within it.