Don't call nitro_runtime_start at the module level

Doing so was breaking code that imports pynitro and then forks
subprocesses. The subprocesses already had the module loaded but didn't
actually have a running Nitro system.

nitro_runtime_start is now called in each NitroSocket constructor. It's
simply a noop if it's already started, so should be safe enough.
Guard nitro_runtime_start with a lock

Suggested by @jamwt to guard against a race where multiple threads are
creating NitroSocket instances.
Merge pull request #3 from dowski/remove-import-side-effect

Don't call nitro_runtime_start at the module level