Fix bad trait declaration for a threading Lock

[mdickinson]

This PR fixes a bad Instance declaration that effectively declared that a _lock trait could only be assigned a built-in function or method (and in particular, could not be assigned a lock).

I really wanted to rename the events trait to _events too as part of this PR, but I can't be absolutely sure that it's not being used elsewhere. (And it is used in the tests, which isn't a great sign.)

No regression test, because I couldn't find a way to exercise the issue using only the public API, and I don't really want to add tests that test internal implementation details. However, if/when we deprecate Instance(some_instance), this code will now fail to give a DeprecationWarning, where the code in master would have given such.

Fixes #1408.
(Recreation of bad PR #1410)

Checklist

• Tests. No test provided. Sorry.
• [ ] Update API reference (docs/source/traits_api_reference). N/A
• [ ] Update User manual (docs/source/traits_user_manual). N/A
• [ ] Update type annotation hints in traits-stubs. N/A

[mdickinson]

In attempting to write a regression test for this, I discovered that on master we already have a test that exercises this quite well, and in that test we do indeed end up creating multiple lock objects in different threads. But it doesn't matter, because in current CPython, the events.append operation is atomic, so the test passes kinda by accident.

I still don't have a reasonable way to write a behavioural test.

[rahulporuri]

LGTM