Handle cancellation in ServiceRegistry.async_call

[pnbruckner]

Proposed change

This is part of a set of incremental changes to enhance the scripting infrastructure. This change will allow cancellation to be used to gracefully stop running scripts, as well as to handle cancellations that happen, e.g., during system shutdown. It also makes sure that when a service call times out the service will be run in the background in such a way that exceptions are properly caught and logged.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

See previously related PR #32442

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

[balloob]

So the biggest change here is that we're no longer shielding things. I suggest we merge this as-is and see how it highlights any issues before 109 is released. If we find some issues, we can decide to apply shields to the scenarios that are failing (thinking Rest/Websocket call service APIs)