Scintilla callback - first steps to fixes

- shared_ptr should not be passed by reference when we don't know how long it will live for
- callback functions now stored as managed boost::python::object's to ensure we keep the ref count correct
- Simple test now passes, and doesn't crash.
- "Per hand" testing occassionally results in crash, can't reproduce in test yet
GIL Manager introduced. Lots of debugging info

Still not right. From the logs it appears the runScript thread reacquires the GIL at the end of add Text,
updates the thread ID in the GILManager, then the UI thread tries to acquire the GIL, *and get's it*, which
can't possibly be the case, unless something is wrong with the GIL calls I'm making.

See the log in notes/Thread-Debug.log
PY>[theadid]   [line number] [text]

Obviously the order of the line number is not definitely the order in which things happened,
but the "after" events *must* be after the event.
Fix notify for SCN_MODIFIED (text is not null terminated)

Use real arguments to call
Add critical section around m_currentThreadWithGIL accesses

Not sure yet if this is necessary.  When all is fixed, we'll take this out again.
Debugging - do not ignore release request from thread that allegedly does not have GIL

After lots of debugging, the issue seems to be the exact race condition mentioned in the comments.
The variable is set or reset out of order with the actual GIL acquisition.

Not having this in will cause an issue in certain other circumstances, so it's only a temporary hack
to prove the issue is just the ordering of the GIL lock/release and resetting the thread ID with the GIL.

Need to understand what order things need to happen in, in order for this to be wrong.
Deadlock solved: replace original thread ID when releasing GIL

Python pulses the GIL inside its main run-loop. What was happening
was that if another thread was waiting on the GIL (eg. our callback consumer)
then that thread stole the GIL, did it's thing, then released it. The pulse
then reclaims the GIL, and execution continues. Problem is then that the
m_currentThreadWithGIL was then reset to 0, as it was released again from
the thread that "stole" it (ie. the callback consumer).

The fix is simple - when taking the GIL, just record which thread had it before.
It will be 0 in the normal case, but in case we've stolen the GIL from
another thread inside a Python exec-loop, it will be the value of the thread
currently running Python code.  When we're done and release the GIL, we just
put it back to its original value, and Python execution grabs the GIL back
and continues as normal.  If our code in this original thread wants to perform
a temporary release, the m_currentThreadWithGIL is correct, and so it knows
to release it.
Remove sleep and more debug info
CallbackExecArgs deallocation bug

CallbackExecArgs contains boost python objects, and was deallocated with a
shared_ptr. Unfortunately this wasn't always when we still had the GIL.
Changed to pointers, then we explicitly grab the GIL when in the destructor.

CallbackExecArgs is now in the namespace NppPythonScript - many other classes
also removed from global namespace.  There's more to do in this area though.
Improved DEBUG_TRACE, printStack()

printStack() doesn't seem to work yet.
editor.write( PyUnicode) fixed

This needs extracting to a helper function, and fixing then generally in the
generator.
Deadlock fixed - release GIL in editor.setSavePoint()

The generator needs to fix release the GIL for every call that could generate a callback.
Debugging info fixed for release variant
Project settings for Release mode, removed unused configurations
ScintillaWrapper::getStringFromObject wraps extraction to std::string

Copes with PyUnicode objects, and strings with NULs in the middle

editor.write('A\x00B')  correctly adds A[NUL]B to scintilla
The generator needs to use this method in all calls where we're able to give a length.
Fix reacquire
Wrapper generation changes

- release the GIL after python types have been extracted
- reclaim it when a python type needs to be constructed
- fixes for various types of calls
  -- colour
  -- getProperty/getPropertyExtended were not generated properly

The generation script could do with a cleanup, but now the output looks ok,
we can always validate the output is correct.
GILLock / GILRelease check if they have the GIL with API

In the case of 3 threads fighting over the GIL, it was possible for a deadlock
to occur, the thread 2 stole the GIL from thread 1, and thread 3 stole from
thread 2.

The API call to check if you have the GIL was added as a helper function
in Python 3.4.0 (issue #17522).  The function is taken from there.  A backport
would be trivial, but that would mean we could only use the packaged
python27.dll, and not the official one.
Generated test cases for ScintillaWrapper

Started implementation, and fixed some issues
We *always* need to release the GIL when we call Scintilla, even if it's just a read.
Something can fire (UPDATEUI), and we are then stuck on the main thread
waiting for the GIL.  If there's *any* callbacks registered, we can deadlock,
even if the notification fired hasn't got a callback, as we need the GIL
to check what callbacks are registered!

Each unique combination of return-type, param1Type, param2Type had a
test case and a callback test case generated. Implemented up to
void_int_colour.
First batch of tests filled out
Fix for getLine() buffer allocation