Added test case demonstrating LRUCache concurrent clear() crash.

This is similar to the recently added ComputationCache clear test, but more directly exposing the underlying problem.
Fixed LRUCache crashes where clear() was called concurrently with get().

The problem was that eraseInternal() was assuming that if status==Cached, the cache entry was in the list already, but in fact that is not the case. Another thread may have loaded the entry and set status to Cached, but not have updated the list yet. We now early out of listErase() if the item is not in the list, and unconditionally call listErase() in eraseInternal() regardless of the current status.

Since this bug stems from the same misconception as the hangs in limitCost(), I've also updated the internal documentation in the header to bang home the message that the status and the list items are not necessarily in sync at any given time.
Fixed mutex acquisition in LRUCache::updateListPosition().

Because the scoped_lock wasn't given a name, it went out of scope immediately. Unfortunately fixing this gives ~11% performance hit in a totally synthetic test, and although we haven't yet seen actual symtoms, it seems best to do things by the book when wandering lost through threading land. Any future optimisations to the LRUCache would probably centre around removing all calls to updateListPosition() for cache hits anyway (replacing them with a "second chance" approximate approach).
Fixed crash in MeshMergeOp.

This was introduced by the recent despatchTypedData DataPtr->Data * change. When AppendPrimVars went through the `if( m_remove )` code path, it was causing the last reference to `data` to be removed, destroying it. But it would then add data into m_visitedData, making another reference and leading to double deletion.

Moving the `m_visitedData.insert( data )` before the deletion fixes the crash. I'm not sure the visitedData logic was actually right in any case (what if the same data is referenced twice on mesh 1, but should be appended to with two different bits of data from mesh 2) - this commit doesn't do anything with respect to fixing that.
Revert "Changing the test so it clears the cache from time to time."

This reverts commit 668cb72701a18841fbcb52bee3e4b8b2d9822c01.

The testing for clearing is now done in the LRUCache test cases anyway, and now the real problem is fixed, the ComputationCache test is erroring at `BOOST_CHECK_EQUAL( size_t(500), cache.cachedComputations() )`, because the size doesn't hit the cache limit any more due to the repeated clearing. It seemed best to retain the original test rather than remove that check and have two otherwise identical tests in ComputationCache and LRUCache.
Merge pull request #304 from johnhaddon/lruCacheClearBugFix

LRUCache concurrent clear() and get() bugfix