use of app_id, app_identifier in both client and lib

[lacostej]

The codes code could be simplified WRT app_identifiers / app_ids.

Current logic:

• both the lib and the client accept app_id, app_identifier, or both
• client also accepts environment variables with some precedence
• in client: if only app_id specified, then app_identifier fetched before talking to the lib
• in lib, app data might be fetched multiple times if only app_identifier passed (FastlaneCore::ItunesSearchApi.fetch and optional FastlaneCore::ItunesSearchApi.fetch_by_identifier call)
• in both client and lib, app_identifier has precedence over app_id

Some of the issues I see:

• client and lib should accept one or the other, to avoid having the folllowing situations
  • both are specified and they don't point to the same app
  • in client, if app_identifier is not specified and app_id is specified but incorrect, we don't fail but instead revert ask the user. We should fail instead, as the user specified an invalid argument. The failure could happen in the client or in the lib (which would also reduce the number of calls to fetch app data)
  • this message is confusing "Maybe the app is not in the store. Pass the Apple ID of the app as well!". Why would passing both solve this ?
• in lib, no need to make 2 calls to fetch app data

So it's possible to make a bit of cleanups. I have a tentative patch to clean this up, (untested) here, available for comments:

https://github.com/lacostej/codes/commits/app_id_identifier_cleanup