Support multi sampled anti-aliasing with wxWidgets 3.0.3.

[bubnikv]

This patch improves rendering of the 3D scenes. The improvement is significant on the 3D path simulation.

1. Increases resolution of the depth buffer from 16 bits to 24 bits. 16 bits cause some jagged lines at the intersection of triangles. I believe the computers offering a 16 bit depth buffer only are already in the landfill.

2. Enables multi sample anti aliasing. This is finally supported by wxWidgets 3.1 (February 29, 2016) and the OpenGL support for creation of anti aliased windows has been back ported to wxWidgets 3.0.3 (currently in beta stage). We at Prusa Research have hacked the Alien::Wx and Wx::GLCanvas to support this feature. Please accept this patch to enable anti aliasing on Prusa builds. This change shall not have any effect with the official non-hacked Alien::Wx and Wx::GLCanvas modules.

Vojtech

[bubnikv]

Here are the patches for Alien::Wx and Wx::GLCanvas to make MSAA working.
These two patches are required to test the feature.
Patches.zip

[lordofhyphens]

You've got unrelated changes added now to the PR (the gcode export changes). -.-;

[bubnikv]

You see, I am really struggling with the git.

[lordofhyphens]

Some good practices for making contributions to Slic3r (IMHO, any upstream project).

1. Each discrete change to the code starts as its own branch. So each feature is a separate branch. Only fixes for that feature go into that branch. Once you're done working on it and it's been pulled where you need it, delete it or leave it alone. Basically treat the branch like it's a set of patches with history metadata attached.
   Rationale: Branches in git are basically free and anyone working upstream want to be able pull in multiple discrete changes than one large blob of unrelated fixes.

2. If you messed up (it happens to the best of us) and have several unrelated changes on a single branch but different commits, create a new branch pointing at before the changes were made, then git-cherry-pick the commits of interest (this is what I'll be doing with your gcode changes and probably this one too). If the commits have a lot of unrelated changes in the same commit, then best to generate patchfiles for the individual files touched for the feature you are interested in and apply them to a branch that starts before the aggregate commits happened.

The less work the project maintainers have to do to vet and merge external code, the more likely it will be that (all other things being equal) the code gets merged in.

As a quick example, see #3349 . I created a branch on my personal fork of Slic3r, lordofhyphens:feature-1333 which originated at alexrj:master. I made the changes, tested them, and then committed them to that branch. Then the pull request got made. When the PR gets merged in (I tend to not merge my own commits in, so someone else can check them as a guard against me derping), I'll delete the branch from my own repo.

I've had my own learning curve with this too with my first few PRs for Slic3r, so I am happy to try to help you too. :)

[lordofhyphens]

Closing this PR because it's been separated out appropriately into two other PRs, #3355 and #3356.