Optimize Apple camera session startup

[jfversluis]

Summary

Closes #319 by making Apple camera-session configuration connection-owned and idempotent instead of moving startup into a property mapper.

Root cause

Initial MAUI property mappings can call UpdateCamera() several times. On iOS and Mac Catalyst, every call rebuilt the AVFoundation input graph and, once running, explicitly stopped and restarted the session. Because AVCaptureSession.StartRunning() is synchronous and expensive, these redundant cycles accumulated into the reported multi-second navigation delay.

Compatibility risks in #320

PR #320 moves the first start from CameraManager.Connect() to CameraBarcodeReaderViewHandler.MapVisibility(). That makes startup depend on a specific mapper invocation and can miss CameraView, custom property mappers that omit visibility, async permission/lifecycle ordering, and Mac Catalyst (where the proposed __IOS__ call is not compiled). It also leaves repeated session reconfiguration in place.

Implementation

• Defer AVFoundation input/output configuration until Connect() runs after camera permission is granted.
• Add the video output and camera input in one configuration transaction.
• Cache the applied camera location, selected device, and resolution selector so redundant mapper updates are no-ops.
• Reconfigure only when camera state or the session graph actually changes.
• Use BeginConfiguration()/CommitConfiguration() while running rather than explicit stop/start cycles.
• Keep initial StartRunning() in CameraManager.Connect(), preserving both handlers and custom mapper behavior.
• Reset cached state on disconnect so reconnect remains safe.

Validation

• dotnet test ZXing.Net.MAUI.Tests/ZXing.Net.MAUI.Tests.csproj -v:minimal (58 passed)
• dotnet build ZXing.Net.MAUI/ZXing.Net.MAUI.csproj -f net10.0-ios -v:minimal
• dotnet build ZXing.Net.MAUI/ZXing.Net.MAUI.csproj -f net10.0-maccatalyst -v:minimal