WSClassVerificationProcessor in full WF misuses ModuleSpecfication by having a DUP for sub-deployment unit X iterate the user dependencies of X's parent and siblings. This sometimes fails with ConcurrentModificationException.

It does this to fix a bug that which would reappear if we corrected that behavior, so let's just make this one collection thread safe.

The WSClassVerificationProcessor behavior is still wrong because it assumes the data for X's parent and siblings are all complete when it reads them, and that is not guaranteed to be true; the parent and subdeployments proceed independently. But even that wrong behavior is less likely to give a bad result (issuing an unnecessary log WARN) than not trying at all.