Support for "capacity" about generictree

[skamradt]

This is implying that the internal number of children is limited to an nativeint so when compiled for 64bit, it can hold more since the limits of a nativeint are larger. Is it feasible to have that many children? Or can it be limited to a FixedUInt/LongWord and still maintain only 8 bytes per node regardless of target? This is an array of children, is 4,294,967,295 not enough for most cases? I would expect the system performance will suffer greatly with that many children (if even possible on 32bit).

If this does move forward, I would suggest a compiler define to determine the max number of child nodes allowed in the array rather than put a memory tax on every node that is not realistic. This way, if someone truly needs more than the 4 billion children on a node, they can recompile with that option on, but the rest of the users would not have to pay the penalty for compiling as 64bit. You already have the redefine for an integer, you could just wrap this around a compiler define and it would be seamless.

Continuing forward I would also suggest a Grow method which given a value of how many nodes to add to the array, would expand the array to allow for that number of new records. If I know in advance that I'm going to be adding a set number of items, this would further reduce the resizing that might otherwise get triggered every n records.

Deletions are also a problem, mass deleting records would potentially leave large gaps at the end of the array. A Pack option would resize the array back down to just what is really available.

An AutoPack public property could be exposed that when set to true would pack the opposite of Capacity.