Add support for iOS (add rubicon-objc)

[timrid]

Description
Now that iOS is an official supported Python platform since 3.13 (see PEP 730), bleak should also support iOS. iOS shares almost the same CoreBluetooth API as macOS. Unfortunately pyobjc is not supported on iOS. Only rubicon-objc is available. So the main work to support iOS is to implement rubicon-objc instead of/in addition to pyobjc.

What I have done
I tried to replace pyobjc with rubicon-obj and tested it on a macOS. After a few hours the Scanner was basically working. So I would like to continue the work on it and get it working on iOS.

Questions

1. If I have a working version in the future, is there a chance that such a PR will be merged?
2. Can pyobjc generally be replaced by rubicon-objc for macOS? (I'm afraid that's not an option, but I wanted to ask the question anyway.)
3. If not, should rubicon-objc be implemented as a second CoreBluetooth backend? That has the disadvantage that much code is duplicated, but the advantage that the current pyobjc based CoreBluetooth backend is not touched. Or should the current CoreBluetooth backend be extended to support both objc-frameworks rubicon-objc and pyobjc? In this way more code is shared, but the risk of regressions is greater.
4. In either way on macOS there would be two possible backends/frameworks available. How to distinguish between the frameworks? My first idea is to add rubicon-objc as optional-dependencies on macOS. So to use this on macOS you have to pip install bleak[rubicon-objc]. But this would also install pyobjc as this is installed by default on macOS. So there has to be an additional runtime parameter, to tell bleak which framework to use. Where is the best place for this parameter?

[dlech]

1. If I have a working version in the future, is there a chance that such a PR will be merged?

If it also runs on macOS, then highly likely.

2. Can pyobjc generally be replaced by rubicon-objc for macOS? (I'm afraid that's not an option, but I wanted to ask the question anyway.)

Maybe eventually, but only if it can be shown to be superior to pyobjc. But pyobjc has been pretty rock-solid over the years, so this would be a very high bar.

3. If not, should rubicon-objc be implemented as a second CoreBluetooth backend?

My suggestion would be to write an abstraction layer for all of the ObjC types and functions that we use. Then we should be able to use the existing backend with minimal changes.

4. In either way on macOS there would be two possible backends/frameworks available.

...

So to use this on macOS you have to pip install bleak[rubicon-objc].

Exactly how I would do it too.

But this would also install pyobjc as this is installed by default on macOS.

We should be able to add ; extra != 'rubicon-objc' to the pyobjc dependencies to take care of that. And we will want a way to install both at the same time for development/testing.