Fix for OCMockObject thread-safety

[kettch]

Synchronizes uses of stubs/expectations/invocations to avoid
thread-safety issues.

[erikdoe]

Thanks for looking into this. I have a couple of comments regarding this pull request.

While putting the @synchronised in as is may work it would be good to apply them with more precision. For example, it would seem that the @synchronised is not needed in _nextExptectedInvocation because this method is only called from handleInvocation which is already wrapped in an @Synchronised. I'm also unsure about wrapping the entire body of handleInvocation: into one large block. Maybe it would be better to extract access to the arrays in question and only guard that access.

Then there is the issue of OCMMacroState. This class is clearly not thread-safe due to the use of a global variable. I would shy away from calling OCMock thread-safe without also addressing this issue.

And with something as complex as this, I really think we would need at least some test coverage.

[kettch]

Indeed, I can look into adding a bit more precision to this. This was just based so far on a quick fix I had done in my specific use cases, so I could verify this was working.

I must admit that I'm not that familiar with the internals of OCMock, so the title of the issue was merely a shortcut to what I was seeing in my integration of it throughout my tests.

I'll certainly try fine-tuning the @synchronize that I added, and adding a few tests to check the behaviour. However, I'm not sure I'd be very confident digging into OCMMacroState (I hadn't even heard of that one before today...). That could be left for another pull request if someone feels up to it and maybe knows that part better than me?

[erikdoe]

Closing this as #235 looks more promising.