PHOENIX-1096 Fix for concurreny bug caused by a cached SequenceExpression using the same byte[] buffer in multiple threads

This is a fix for the Upsert...Select issue we ran into when using Sequences in the SELECT portion of the statement. We were generating mutations with identical row keys because multiple rows were being assigned the same sequence number. I tracked this down to the fact that we cache SequenceExpression and have a member field byte[] where we store the sequence after reading it. This buffer was being written to by multiple threads and so there was no guarantee a thread would see the sequence it read and based on timing multiple threads would read the same sequence when generating the row key for the mutation. 

Moving the buffer to a local variable addresses this issue.

I have also included a test that Samarth and I created to repro the issue that is now passing.
In order to reliably repro this issue we needed a higher level of concurrency that the defaults and there we need to override the default thread pool size to 64 so we can have 64 salt buckets.