DynArrays is a library which provides several dynamic array datatypes:
1D array of Byte, Word, DWord and PtrUInt (Pointer)
2D array of Byte and Word
3D array of Byte

Tested on (depending on available memory):
  - Desktop (32-bit FreePascal)
  - PIC32MX270F256B
  - PIC32MZ2048EFM144
  - dsPIC33EP512MU810

Features:
- The library comes as a .pas file, which is included by a .mpas file, so it can be compiled for Desktop compilers (e.g. FreePascal) and MCU (mikroPascal for dsPIC and PIC32).
- Various library features can be switched on/off, using compiler directives.
- There are various functions for array initialization, setting length, freeing, adding items, removing items, concatenation etc. Not all datatypes are made equal. Some have more features than others. For example, the arrays of Word and DWord have functions for creating unique values, stored in arrays themeselves.
- There are conversion functions to and from string, for some of the array types.
- Most functions return a boolean result for successfully allocating or reallocating memory.
- Since memory fragmentation is a risk of not being able to allocate more memory, although available, a simple solution was to redirect GetMem and FreeMem calls to two library functions, which modifies the requested datasize, to be multiple of pointer size. This is enabled by defining RoundAlloc compiler directive at project level. This feature causes the fragmentation to be drastically reduced.
Also, to change the number of available memory blocks, in MemManger, the NR_FREE_BLOCKS can be modified like:
{$IFDEF MMFreeBlocks}
  const NR_FREE_BLOCKS = {$I MMFreeBlocks.inc};
{$ELSE}
  const NR_FREE_BLOCKS = 20;
{$ENDIF}

By providing a new MMFreeBlocks.inc file per project, then every project can have its own NR_FREE_BLOCKS value.

Dependencies: MemManager

Requirements:
- Because the compiler's built-in MemMove function is limited to copying a maxium of 65535 bytes, a new function had to be redefined (MemMove32), which is limited to 2147483647 bytes. When required, it can be enabled, by defining RedefineMemMove compiler directive at project level. A similar function, Min32 is defined, to replace the existing Min function, for the same reason. If user applications do not require allocating more than 65535 bytes per array, then the built-in MemMove function is used instead (when RedefineMemMove compiler directive is not defined).
- In MemManager, the MM_error function header has to be uncommented.

Usage example (1D array of Byte):

var
  Arr: TDynArrayOfByte;
begin
  InitDynArrayToEmpty(Arr);  //required, to initialize internal structure (length to 0, and pointer to nil)

  if not SetDynLength(Arr, 3) then // allocate memory
  begin
    //log out of memory error;
    Exit;
  end;

  Arr.Content^[0] := 30;
  Arr.Content^[1] := 40;
  Arr.Content^[2] := 50;

  if not AddByteToDynArray(60, Arr) then
  begin
    //log out of memory error;
    Exit;
  end;

  FreeDynArray(Arr); //deallocate memory
end;

Limitations:
 - Not optimized for efficient memory reallocation.
 - Only the above mentioned datatypes are available.
 - Most functions share the same code, i.e. the code is duplicated for the new datatypes.
 - Most functions require more than double the current array size to be available, when reallocating.
 - CheckInitialized<DynArray> functions are available on Desktop only. They raise exceptions when other functions are attempting to use uninitialized arrays. Since compilers do not automatically insert initialization code (i.e. they do not manage these datatypes), users will have to call InitDynArrayToEmpty-like functions, for every new array.
 - The reported memory usage will not be the same on Desktop and MCU, because on Desktop, more memory is required. This is because the datastructures are a bit different on Desktop (they contain one more field), which are allocated using New, instead of GetMem (to be properly initialized).

Known issues:
  - CreateUniqueWord and CreateUniqueDWord functions might return unexpected values when their arrays are full.

Tested with:

https://libstock.mikroe.com/projects/view/5702/expectations