Read `FASTLANE_SKIP_TOOLKIT_UPDATE_CHECK` in `check_for_toolkit_updates` action

Currently, projects such as WordPress iOS use check_for_toolkit_updates in combination with the FASTLANE_SKIP_TOOLKIT_UPDATE_CHECK environment variable as a way to bypass the process. E.g.

check_for_toolkit_updates unless is_ci || ENV['FASTLANE_SKIP_TOOLKIT_UPDATE_CHECK']

Having the env var spelled out at the project level is convenient for discoverability, but I wonder if we would be better served "at scale" if the command itself read that env var, and possibly the is_ci value, too.

Doing so would streamline adopting the command ("action", really) to simply calling it.

We could compensate for discoverability by:

• Adding a message as part of the output informing users of the env var existence
• Adding a force parameter to bypass those internal checks

Start at the implementation of the check_for_toolkit_updates action and trace how it currently performs its checks. Review the existing FASTLANE_SKIP_TOOLKIT_UPDATE_CHECK and is_ci behavior, then decide how output messaging and a force parameter should interact with them. Done means the chosen behavior is documented in tests and the action can be called without project-level bypass logic.