Allocator-construct the owned object by conditionally forwarding the allocator to the object's allocator-extended constructor

[jbcoe]

In #249 I've tried to conditionally forward the allocator to the owned object T (or U) by adding an allocator argument to the control block and calling C++20's make_obj_using_allocator or uninitialized_construct_using_allocator to construct the owned object.

These functions work by checking to see if the object std::uses_allocator<A>::value is true and if it is, then calling one of two allocator-extended constructors. For a constructor taking args Ts... the allocator extended forms tak std::allocator_arg_t, Allocator, Ts... or Ts..., Allocator. I've tried to capture this all in the test I added in allocator_test.cc.

Sadly, AppleClang14 and C++14, C++17 don't support make_obj_using_allocator or uninitialized_construct_using_allocator.
I've also seen that uninitialized_construct_using_allocator uses std::construct_at and not allocator_traits::construct. This means the construct method of a custom allocator won't get called. This feels weird and means I had to disable the tagging allocators tests in #249.

We need to create C++14-compliant versions of uninitialized_construct_using_allocator and make_obj_using_allocator (the first is the most important). These need to work by calling allocator_traits::construct so that the tagging tests continue to work. This is far too much template-meta-programming for me to be willing to tackle on a Sunday morning.

[jbcoe]

After discussion with @NinaRanns, I don’t think that the behaviour introduced by this PR is desired.