Multiple init

[ben]

As discovered in libgit2/libgit2sharp#517, initializing the threadsafe mechanisms multiple times doesn't seem to have any ill effects, but bad things would start to happen after the first call to git_threads_shutdown.

This PR converts the status variables to be something like a reference count, and the global threading primitives are only freed once the counter reaches zero.

[arrbee]

If this returns > 1, you still have to spin waiting on git__initialized to be > 0 so that later threads will wait for the first thread to finish initialization.

[ben]

Okay, this last couple of commits should guard against this race:

1. The last shutdown call is received, triggering teardown—
2. And a wild init call appears, and tries to set up those same resources.

I kind of want to squash this all down when it's finalized. I hate to have points in our history where this specific API is so terribly broken.

[vmg]

I am a little concerned with the fact that this is over-engineered because @arrbee's initial code for deinit was also over-engineered.

Is the thread-safe and multi-shutdown API we have right now really necessary? I think one global init and one global shutdown should be the goal of all the people using the library. Can you think of use cases where this multiple initialization is a requirement?

[ben]

Libgit2Sharp has one, actually. A server process (like IIS) can spin up multiple AppDomains in a short period of time, and the static constructor for Libgit2Sharp.NativeMethods (which calls git_threads_init) will be called more than once. None of the AppDomains have any access to each other's managed memory, so none of them can know if the init has been called before at that level – we have to do it in native code.

[ben]

Squashed up, and Travis and Janky are happy. I think this is ready.

[vmg]

Threads are C R A Y. Thanks for tacking this, guise!