Creating `SSLContext` at import time makes mocking "impossible"

### Is your feature request related to a problem?

Hi there, I am the author of Mocket.

Mocket is probably the only tool around able to mock non-blocking sockets, and it's also listed under https://docs.aiohttp.org/en/stable/third_party.html.

With `aiohttp==3.10.6` you moved the creation of `SSLContext` at import time.
This makes mocking HTTPS calls impossible if applying an agnostic approach which works for every client (mocking `socket` and `ssl`).
To fix that on my side I'd have to change Mocket for mocking `aiohttp` internals: `_SSL_CONTEXT_VERIFIED` and `_SSL_CONTEXT_UNVERIFIED`.

### Describe the solution you'd like

Just an hint to understand my point. I leave to you folks the decision about the possible change.

Change `_make_ssl_context` (in `connector.py`) to make it fail (e.g. add `1 / 0` as its first line).

```python
>>> import aiohttp
Traceback (most recent call last):
File "", line 1, in
File "/tmp/aiohttp/__init__.py", line 6, in
from .client import (
File "/tmp/aiohttp/client.py", line 85, in
from .connector import (
File "/tmp/aiohttp/connector.py", line 757, in
_SSL_CONTEXT_VERIFIED = _make_ssl_context(True)
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/employee/repos/python-mocket/aiohttp/connector.py", line 737, in _make_ssl_context
1 / 0
~~^~~
ZeroDivisionError: division by zero
```

### Describe alternatives you've considered

I don't like the idea of stopping supporting `aiohttp`, but I don't want `Mocket` to adapt to clients' internals, because it's exactly the opposite approach (mocking `socket`/`ssl` VS mocking clients).

### Related component

Client

### Additional context

_No response_

### Code of Conduct

- [X] I agree to follow the aio-libs Code of Conduct