IDE Support

A major part of contributing to a large codebase is support for a particular IDE. This lowers the barrier to entry for a particular project because it gets developer hands on the code quicker.

### Choosing an IDE

* [ ] Based on my conversations with two professional C++/Qt developers, QtCreator is a professional grade IDE that works well for most of the above purposes so that will be the initial focus of this task. There are also commercial IDEs as well as platform-specific IDEs that can also do the trick. Often, developers don't even use an IDE and use `nano`, `vi`, `gedit`, `kate`, `notepad++`, `atom`, `sublime`, etc. This is OK too!... but they are out of the scope of this task.

### Objectives

* [ ] **Setup**: The initial setup of the IDE. This will vary depending on platform, but short steps on how to install and configure the build environment can speed things along.
* [ ] **Building**: This is arguably the most important part if an IDE is used properly. The play button should properly build the source code and run the application.
* [ ] **Debugging**: Hand-in-hand with building, but often the IDE has special steps for inspecting/watching a particular part of code. A video may be better than a wiki in this case, but debugging steps are important if an IDE is to be used properly for hunting bugs (which we have plenty of)
* [ ] **Dependencies**: 3rd party dependencies must be recognizable by the IDE so that the project will build and to encourage code completion. Adding new dependencies should be documented/relatively easy as well to encourage new feature development.
* [ ] **Code Styling Steps**: This is important because PRs become a wasteful back-and-forth when spaces/tabs are the only thing preventing good code from being merged. Pre-configuring an IDE with code styling is extremely important to prevent frustration with otherwise perfectly good code.
* [ ] **Version Control**: Most IDEs have `git` integration, but this shouldn't be taken for granted. Sometimes, committing and pushing can be hard to find in the IDE. Also, there are often built-in `diff` features which are a good part of the pre-commit-review process. We should provide basic steps for the review-commit-push process.
* [ ] **Branching**: The topic of branching is an interesting one because we don't really spell out the fork-branch-PR-commit process. This is is more of a "GitHub" best practices, but we should either link to an official document on this or write our own so that developers don't get burnt-out accidentally editing the unpushable `upstream`.

Here are two videos that I was given permission to share by @curlymorphic that tackle a lot of the above using an IDE called "Qt Creator".

* **Initial Loading** http://youtu.be/XTWnQPGL9xs
* **Tips and Tricks**: http://youtu.be/3OzGXfm6fqE

The issue names Qt Creator and lists setup, building, debugging, dependencies, code styling, version control, and branching as documentation objectives, but it names no repository files or tests. Start by reviewing the two linked Qt Creator videos and the project's existing contribution and build guidance; done means a focused guide covers the listed workflow clearly.

Written by the indexing model from the issue text.