feat(mobile): cancel BlockOperation in iOS RemoteImageImpl

[LeLunZ]

Description

Previously we could have queued a BlockOperation, cancelled it, and it would have launched a new thread just to check isCancelled.
With the changes in this PR the BlockOperation does internally in its start method see that the request got cancelled and just aborts launching a new thread.
I made the BlockOperation a part of the RemoteImageRequest and also cancel it incase request.cancel is called.

The kind of annoying part: we need another lock because we add the BlockOperation in the request thread, and read it from the main thread to call cancel on it.

I think conceptually this is cleaner, but performance wise I didn't see any positive/negative impact when comparing request/cancellation timings.

I also thought about just creating an empty BlockOperation in the main thread when creating the request, but then we would have to call operation.addExecutionBlock later. I think the whole BlockOperation is thread safe so this shouldn't be a problem. But I am then not sure what kind of lock they are using internally and that could be anything (possibly worse in performance than the UnsafeLock).

(Also removed id property from RemoteRequest as this wasn't used anywhere)

How Has This Been Tested?

• Simulator: scrolling thought the timeline
• Compared request/cancel timings vs the base in refactor(mobile): iOS introduce ImageRequest base class with unified cancellation and finish helpers #27489 Didn't find any meaning full difference.

Checklist:

• I have carefully read CONTRIBUTING.md
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if applicable
• I have no unrelated changes in the PR.
• I have confirmed that any new dependencies are strictly necessary.
• I have written tests for new code (if applicable)
• I have followed naming conventions/patterns in the surrounding code
• All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc.
• All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/)

Please describe to which degree, if any, an LLM was used in creating this pull request.

[LeLunZ]

Closing this for now as the base PR won't get merged as #27672 exists now