Fix error handling deadlock.

@tapir and @shurcooL PTAL and let me know what you think.

This is an alternative fix for #92 (see most discussion in #86).

The original test program would output:

```
App started
Error 65540: Invalid window size
Error 65540: Invalid window size
GLFW: Uncaught error: 65539 -> Invalid argument for enum parameter
No deadlock
```

Which of course is incorrect (you should see two uncaught errors). Instead, we make it such that a call to Terminate flushes the pending errors so they are printed properly before the program exits.

The original test program (incorrectly) did not invoke Terminate, so a proper version is provided:

```Go
package main

import (
    "runtime"
    "fmt"
    glfw "github.com/go-gl/glfw3"
)

func init() {
    runtime.LockOSThread()
}

func main() {
    glfw.Init()

    fmt.Println("App started")

    // Here is an error that is caught
    _, err := glfw.CreateWindow(-5473548, 2354234, "Testing", nil, nil)
    if err != nil {
        fmt.Println(err)
    }

    // Here is another error that is caught
    _, err = glfw.CreateWindow(-5473548, 2354234, "Testing", nil, nil)
    if err != nil {
        fmt.Println(err)
    }

    // Here is two uncaught errors
    glfw.WindowHint(-23123, 0)
    glfw.WindowHint(-23123, 0)

	glfw.Terminate()

    fmt.Println("No deadlock")
}
```

Which when ran has the correct output:

```
App started
Error 65540: Invalid window size
Error 65540: Invalid window size
GLFW: Uncaught error: 65539 -> Invalid argument for enum parameter
GLFW: Uncaught error: 65539 -> Invalid argument for enum parameter
No deadlock
```

It's OK that we require users to invoke Terminate to get correct output; as GLFW itself already requires this. If you don't invoke Terminate for instance the monitors gamma/resolution/etc may not be set back to correct values; *a program not invoking Terminate is an incorrect program period.*

This doesn't solve the fact that each GLFW function still needs to return an error for proper handling -- but this solves the immediate deadlock issue and doesn't suffer from the (implicit) data races in #92.