Fix: Support self application of Buffer.append

[matthewhammer]

Appending a buffer with itself causes divergence, which may surprise or disappoint some developers.

Possible fixes:

1. Keep same behavior (diverge)
2. Check for this case and trap, failing fast, with an assertion failure within Buffer.append
3. Iterators keep their own state about when to stop, copying it from the Buffer's internal variables (same outcome as first cloning arg before using it for appending, but more efficient).

This PR uses solution 3.

Rationale: The current "problem" is that there's a read-write dependency between the buffer's size when appearing as an argument, and when (also) appearing as the receiver of the append invocation. To permit this call with the expected functional behavior, we just need to break this dependency (copying the number of buffer elements to read before increasing this variable). This PR does that with a minor remedy to the code.

[chenyan-dfinity]

Why do we want to allow this? The result is tied closely (maybe too close) to the evaluation order, e.g. what's the result of c.append(c.append(c)).append(c). The clone() approach makes this explicit, which is less likely to introduce bugs.

[matthewhammer]

Okay, so you dislike option 3. I can understand why.

So, do you want to choose options 1 or 2 (see my list)? Or add other design option?

[chenyan-dfinity]

I think option 2 makes sense. They can always clone the buffer if they want to self append. I would expect append to be associative. Self append breaks that rule.

[rossberg]

let?