Add accumulative allocation tracking to allocators

[JimBobSquarePants]

Prerequisites

• I have written a descriptive pull-request title
• I have verified that there are no overlapping pull-requests open
• I have verified that I am following the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
• I have provided test coverage for my change (where applicable)

Description

Fixes #2850

This pull request introduces a new accumulative allocation tracking system to the MemoryAllocator infrastructure, allowing for a configurable cap on the total memory allocated over the allocator's lifetime. It adds new configuration options, implements tracking logic, and updates all relevant allocators to enforce and release this new accumulative allocation limit. Other minor improvements include enhanced documentation and some code style refinements.

Accumulative Allocation Tracking and Limits

• Added an accumulative allocation limit to MemoryAllocator, configurable via the new AccumulativeAllocationLimitMegabytes property in MemoryAllocatorOptions. This limit is enforced across all allocations, with platform-specific defaults (2GB for 32-bit, 8GB for 64-bit processes). [1] [2]
• Implemented logic in MemoryAllocator to track total allocated bytes, reserve/release allocation, suppress tracking during batch operations, and wrap allocations with a tracking owner that releases the reservation upon disposal. [1] [2]
• Updated SimpleGcMemoryAllocator, UnmanagedMemoryAllocator, and UniformUnmanagedMemoryPoolMemoryAllocator to enforce the accumulative allocation limit and to properly track and release allocations. [1] [2] [3] [4] [5]

Configuration and API Improvements

• Extended MemoryAllocatorOptions with the new AccumulativeAllocationLimitMegabytes property, including validation and documentation. [1] [2]
• Improved XML documentation throughout the allocator APIs to clarify the new behaviors and configuration options. [1] [2]

Interface and Code Style Enhancements

• Made interface members in IMemoryGroup<T> explicitly public for consistency and clarity. [1] [2] [3]
• Minor code style and documentation improvements in buffer and enumerator implementations. [1] [2]

These changes collectively provide stronger safety against excessive memory consumption, offer more configurability for consumers, and improve maintainability and clarity of the memory allocation subsystem.

[antonfirsov]

I'm planning to take a look later this week.

[JimBobSquarePants]

@antonfirsov Thanks mate!