Separate ObjectPool into static and dynamic parts

[cecille]

Problem

The general goal of this refactor is to separate the static and
dynamic parts of the ObjectPool so that developers that support
heap allocation can also opt to use static allocation for portions
of their code. This refactor maps ObjectPool to the same default
types as current (dynamic if heap allocation is allowed, static
otherwise).

Upcoming refactor PRs:

• adding unlocked iterator access so we can use range-based for
  loops (works more easily with the design of certain part of the
  SDK stack)
• Demonstrating the use of the unsized abstract base type pointer
  for passing pools of unknown size

Change overview

Separates the static and dynamic portions of ObjectPool into two classes and provides a default mapping to ObjectPool based on the config setting.

Testing

ObjectPool tests pass. Also affects inet tests (also passing).

[yufengwangca]

I think the purpose of this refactor is not to allow developer to use dynamic and static pool simultaneously. This decision should be made based on the platform capability and invisible to developers.

[kpschoedel]

I think the purpose of this refactor is not to allow developer to use dynamic and static pool simultaneously. This decision should be made based on the platform capability and invisible to developers.

So, this came up again because I ran into a painful inconsistency in ObjectPool: in the heap implementation, the object constructor gets called, but in the static implementation it doesn't.

I'm agnostic as to whether the programmer should be able to force a static pool, but in practice they can and do today by using BitMapObjectPool. That is mostly a nicer static pool than this one, since it doesn't require objects to inherit from System::Object, and (like the heap ObjectPool) does invoke the constructor/destructor.

BitMapObjectPool however doesn't provide Retain/Release. That is used only by TCPEndPoint.

There's the additional question of synchronization. The CHIP rule is that the SDK is not thread-safe, although it's not (yet) clear that all uses behave correctly. In Weave, the Object synchronization was required internally by AsyncDNS, but we don't have that. (BitMapObjectPool does synchronize.)

What I propose:

• System::Object goes away.
• The heap allocator here moves to Pool.h and gets the same API as BitMapObjectPool, i.e. not requiring Object as first superclass.
• Move Retain/Release to TCPEndPoint (probably via a mixin).

[msandstedt]

I support @kpschoedel's suggestions. The reference counting is one of the most difficult things here. If we can move this into the class or classes that actually need it, that would simplify things a lot.

[msandstedt]

Looks like this will be good to go once @bzbarsky-apple 's comments are addressed.

[andy31415]

/rebase