Fix memory leak in singleton_object_pool

[mxz297]

Two memory leak fixes related singleton_object_pool.

1. The singleon_object_pool currently only destructs objects but does not deallocate memory space. This leak applies to all architectures.

2. On ppc and arm, instruction decoder does not use smart pointers to manage InstructionAPI::Instruction constructed by a singleon_object_pool, and thus cause memory leaks.

[mxz297]

This PR should help with memory leaks caused by InstructionAPI and dataflowAPI. It does not help SymtabAPI.

My experience is that memory usage of code parsing for a binary with 170MB .text size decreased from 12.0GB to 9.3GB on x86. The impact on power or arm can be larger. I have a run that rans out of memory on zeroah, which has 64GB memory, and now it can finish with about using 7GB memory.

[mxz297]

Instrumenting all functions libxul.so used to need about 64GB memory. Now it needs about 48GB. Still a lot of memory is needed, but a decent reduction.

[hainest]

https://bottle.cs.wisc.edu/search?dyninst_branch=PR835

Testing looks good. You can ignore the regressions; they are unrelated non-deterministic test_reloc failures. I agree we should split this PR into allocator changes and decoder changes. I can do that, if you don't have time.

[mxz297]

@hainest This PR contains changes both to the allocator and the decoder, but the changes are only for fixing memory leak. Just want to clarify that I think the improvement to the allocator should be done in a separate PR. I don't think we need to split this PR to two parts. So, if there is no regression, I am good to merge this.

[hainest]

@mxz297 I would prefer to split this one since the change to the instruction decoders is an API breaker, but the change to the allocator isn't. I can split these so you don't have to.

[mxz297]

@mxz297 I would prefer to split this one since the change to the instruction decoders is an API breaker, but the change to the allocator isn't. I can split these so you don't have to.

No, my changes to the decoders are internal. Note that the changed header files are internal header files. These are not public header files. So, this PR is not breaking API.

[hainest]

Oh, I didn't see that. Agreed. Merging.