Adds an IntArray pool to MacroEvaluator.Session and modifies Session's ExpansionInfo pool to match the pattern.

[tgregg]

Description of changes: The main idea here is that Session manages all pools relevant to macro evaluation. This works well because Session instances are already reused, so we can just reset its pools in bulk in Session.reset(), rather than worrying about releasing individual items back into their pools. I modified the existing ExpansionInfo pool to match this pattern, as well as adding a new IntArray pool for the array used to track argument end indices. This reduced allocation rate.

Speed: 247 ms/op -> 245 ms /op (-<1%) Allocation rate: 175 KB/op -> 163 KB/op (-6.9%)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[tgregg]

With this we have by my count 6 pool use cases in ion-java.

Using Pool/Poolable:

* utf8 string encoder pool

* utf8 string decoder pool

* bytebuffer pool

Not using Pool/Poolable:

* Block allocator pool

* expression pool

* expander pool (this)

When do we use Pooled/Poolable, and when not?

Pool/Poolable is a fairly heavy-weight abstraction that is good when the resources are fairly large, infrequently accessed, and accessed/freed individually. The BlockAllocator could be migrated to the Pool/Poolable abstraction if we felt like spending the time to do so.

For expressions and expanders, we need to access chunks of many at a time, and they can all be freed at once. Pooled/Poolable is heavy for this use case.

[tgregg]

Closing in favor of a different evaluator design.