refactor: Split init call of Plugin & PluginGLFW

[pchampio]

The Plugin interface doesn't need a glfw.Window to be instantiated.
Calling the init function of the Plugin interface before the glfw.Window is created improves the app's flexibility.

Example of why it's needed: draft-wiki answering the issue #137

[GeertJohan]

This breaks the order in which plugins are fully initialized. Currently the user can determine an order by adding the plugins in a certain order. Which is no longer the case when GLFW plugins are always initialized after 'normal' plugins.
Also, the provided use-case introduces a flaw for users that want to initialize multiple windows. One borderless and one normal. If the Application manages bordres and/or fullscreen, then it can set the window hints right before creation, and reset them after creation. That way a user can have 2 Applications with different options, instead of abusing the Plugin system to set GLFW options.
Lastly, if we move to go-glfw/glfw 3.3, then the plugin won't work anymore because it sets the window hint in the GLFW 3.2 package. Afaik there is no compatibility between the packages and they each have their own GLFW namespace/globals. So setting the window hints in the GLFW 3.2 package won't affect GLFW 3.3 windows.

[pchampio]

Thanks for your detailed feedback, closing the PR.