Refactor AzDataTableService from a single file

[PalmEmanuel]

Summary

AzDataTableService has grown to cover connection setup, standard CRUD/query flow, transaction batching/fallback, large-entity orchestration, and PSObject projection. This issue tracks a staged refactor to improve maintainability without changing behavior.

Scope

Implement both phases:

1. Phase 1 (structure-only): split AzDataTableService into partial class files (no behavioral changes).
2. Phase 2 (targeted extraction): extract key collaborators for projection and transaction submission while preserving public API and behavior.

Why

• Improve readability and reviewability of changes.
• Reduce risk of regressions from unrelated edits.
• Make testing and future logging work (e.g., Add support for logging to PowerShell streams from AzBobbyTables.Core assembly #141) easier to localize.

Phase 1: Partial class split (no behavior change)

Create partial files under source/AzBobbyTables.Core/:

• AzDataTableService.Connection.cs
• AzDataTableService.StandardEntityOps.cs
• AzDataTableService.LargeEntityOps.cs
• AzDataTableService.Transactions.cs
• AzDataTableService.Projection.cs

Phase 1 acceptance criteria

• Public API surface of AzDataTableService remains unchanged.
• No functional changes to runtime behavior.
• Existing tests pass unchanged.
• File boundaries are responsibility-based and methods are moved intact.

Phase 2: Extract collaborators (incremental)

Extract internals behind focused components, keeping AzDataTableService as orchestration/facade:

• ITableEntityProjector (PSObject projection)
• ITransactionSubmitter (batching and individual fallback behavior)
• Optional: ILargeEntityCoordinator (split/reassembly/remove orchestration)

Phase 2 acceptance criteria

• AzDataTableService public methods and cmdlet behavior remain unchanged.
• Extracted components are covered by existing tests and any needed focused unit tests.
• No change in transaction semantics, retry behavior, or reassembly outcomes.

Suggested execution plan

1. Submit Phase 1 as a dedicated PR (mechanical move-only).
2. Submit Phase 2 as follow-up PR(s), one collaborator at a time.
3. Keep each PR small and behaviorally neutral; run full test suite after each.

Out of scope

• New features
• Logging bridge implementation itself (tracked separately in Add support for logging to PowerShell streams from AzBobbyTables.Core assembly #141)
• API-breaking changes