Create `FlxToolbar` to avoid duplicate code

[IQAndreas]

Taken from #153 (comment)

There is a lot of repeated code inside of Vis and VCR which could be removed by giving them a common base class FlxToolbar (which would potentially allow for more toolbars to be able to be added in the future with ease). There are also a lot of hard-coded values which should be more dynamic.

[greysondn]

I'll take the first part of this one in my dev team's repo, if you'd like :3

If someone beats me to it - well, no problems. Just wanted to drop a note that I was started on it.

I doubt I mess much with the hard-coded values, however. It'll have to wait for me to see.

Edit: By Nature, Adam!

http://pastebin.com/CMCx1PhU

That is not how object oriented code works!

It may make sense to add cleaning up such messes (there are undoubtedly more, and undoubtedly many found already) to the list of things to do. Also worth asking is whether or not it's possible to get by with using FlxButton and FlxGroup for much of the same work he's doing in this code. (Indeed, I'm debating if I want to personally tear it down and build it back up as such right now.)

[greysondn]

I've issued a pull that gets the worst part of the refactoring and cleanup out of the way. It's not the full issue request, but it's a solid start.

Please see:
#160

[Dovyski]

Amazing job and thanks for the contributions so far, @greysondn ! I've checked your code superficially and it looks good.

About the cleaning up you mentioned, I think we will perform a few of them in the future. That's one of greatest things in open source communities, the code evolution. I've spotted some tweaks we can do in FlxSprite, for instance.

We certainly can continue to work on your current re-factoring, issuing and merging more pulls.

[greysondn]

At this point I've cleaned up the docs per my own added todos and looked over the code to see the actual feasibility of adding it in to the main base. (EDIT: Sorry; not had my coffee yet. I mean, using our usual classes such as flxGroup and flxButton, etc - instead of these hacked together ones that Adam has implemented to sidestep various issues that could cause.)

I think it's not only possible but actually makes sense. If I understand correctly, @IQAndreas has a branch where substates are implemented - once that's in this dev branch (if it finds its way in, more on that in a moment) then the debugger and overlay may be able to be implemented as a substate of all states; eg: flxGame ==> myMain ; or flxPlaystate ==> myPlaystate

Failing that, still I see no reason why there couldn't be some way to rewrite part of this with flxButtons at the least. Spacing could be noted as well as the bar's actual position and then adding a new member is as "easy" as a call to a function that would have to be implemented for that purpose, with indication of pressdown, hover-over highlighting, etc.

However; that's broadly ambitious work that I may be speaking naively of, so let me ask more specifically:
What else would you like to see done on this fix? I know allusions are made to hardcoded variables; what exactly, if any, came up in prior discussion or in mind when this issue was created?

I have some time off and on today - lunch and a few other points - to implement more incremental fixes towards the end goal on this. Please advise.

Thanks!