Fix potential StackOverflowError when many elements/tokens/activations added to working memory


There is potential for a `StackOverflowError` to be thrown in a few scenarios:
1. A large number of elements are added via `clara.rules.memory/add-elements!` from right activations.
2. A large number of tokens are added via `c.r.m/add-tokens!` from left activations.
3. A large number of activations are added via `c.r.m/add-activations!` from rule activations.


The reason for this is that these `add-*!` functions are "piling" up successive calls to `concat`, which is lazy.
When this seq of `concat`ed elements is realized, it needs _n_ number of stack frames to get the first (and successive) element(s) , where _n_ is the "large number of elements/tokens/activations added via" an `add-*!` function.


This looks something like (example from `add-elements!`):
```clj
(concat previous-elements elements)

```


The most obvious solution to this problem is to swap the `concat` with a `into` instead, which is eagerly evaluated.
However, it is worth considering if the eager evaluation of `into` is appropriate.  Is there a good reason to perform these operations in a lazy manner?  It is not immediately clear to me.


**Also, note that `c.r.m/add-insertions!` has the same nested `concat` call structure in it.  However, I have not reproduced this in a test case yet.  I believe it may need to be addressed in the same way as the 3 places addressed in this issue.  I have left it alone currently.**


Issues like this have been discussed in a number of different threads, but http://stackoverflow.com/questions/5294055/why-am-i-getting-a-stackoverflow  is one example.

In my test cases, I have set the addition count `n` to 6000.  Around ~4K additions to memory is where the StackOverflowError comes up (i.e. whatever the call-stack limitation is).

I've written tests to expose the 3 points above.  I have noted that using batch insertions in these test cases, could workaround the issue.  However, I'm not sure that the memory should be implemented in a way that relies on the rules using batch insertions in all cases where there may be a lot of added elements/tokens/activations.