Marshal strings as UTF8 (affects #18)

Starting with OpenGL 4.2, strings passed to GL.ShaderSource are allowed
to contain multi-byte characters in comments (issue #18). This patch
modifies the marshaling code to use UTF8.GetBytes in order to marshal
strings, instead of Marshal.StringToHGlobalAnsi().
Marshal strings as UTF8 (affects #18)

Starting with OpenGL 4.2, strings passed to GL.ShaderSource are allowed
to contain multi-byte characters in comments (issue #18). This patch
modifies the marshaling code to use UTF8.GetBytes in order to marshal
strings, instead of Marshal.StringToHGlobalAnsi().
Merge branch 'utf8' of https://github.com/opentk/opentk into utf8
Merge branch 'utf8' into utf8_test
shader source with Japanese comment test
Merge branch 'develop' into utf8
Merge branch 'develop' of https://github.com/opentk/opentk into utf8
[OpenTK] Use ASCII encoding

Most OpenGL versions work with single-byte ASCII strings exclusively.
OpenGL 4.2 adds UTF8 encoded comments to GLSL shaders. Unfortunately,
UTF16 (.Net) to UTF8 conversions will usually modify the length of the
resulting byte array.

This is not currently possible to implement inside OpenTK, since the
binding generator does not know which length parameter corresponds to a
string parameter.

For this reason, and to maintain compatibility with older OpenGL
versions, we perform a destructive UTF16-to-ASCII encoding, which
replaces unsupported characters by '?'. This allows multi-byte post-4.2.
GLSL shaders to work as expected.

If non-destructive round-tripping of strings is required, the user will
have to use the IntPtr overload for string parameters and perform the
UTF16-to-UTF8 encoding/decoding manually. This need is very unlikely to
arise in practice.
Merge branch 'utf8_test' of https://github.com/ganaware/opentk into utf8
[Examples] Move UTF8 sample to Test folder
Merge branch 'utf8' into develop
[Win] Fix X1/X2 mouse buttons (fixes issue #27)
[GLControl] Use dummy context in design mode

Creating a GraphicsContext with null parameters is not a guarantee that
we will get a dummy context that does not call any OpenGL functions. We
need to explicitly define and construct a dummy context that is safe to
use inside the designer.

Affects issue #49
[Win] Implemented calli-based interop for WGL
[Win] Removed WGL delegates in favor of calli
[Win] Clear extension list on reload
[OpenTK] Removed unused GraphicsMode field
[OpenTK] Clamp max AA level to 64x

This protects against a potential denial-of-service issue during mode
selection, where the platform backend will try to reduce AA level until
a supported mode is found.
[OpenTK] Allow a GraphicsMode.Buffers value of 0

0 in this case means “don’t care”.
[OpenTK] Moved RelaxGraphicsMode to Utilities

This functionality is useful for all platform backends and is not
specific to the X11 backend.