Add proper states for debugging command buttons

[gregtatum]

This resolves issue #96.

I believe there is an existing error with waiting for the next break point that involves loading in source code. However despite that error I believe this will correctly handle the possible button states.

There is a slight flicker on the play/pause button when stepping over code. This is due to the way that the inline svg module loads in the SVG. I also took the liberty to refactor some of the CSS to make the button hit areas more consistent.

What's the current state of testing? I noticed there wasn't too much in there, so I didn't include any with this pull request.

[gregtatum]

Hmm... forgot to re-run the tests when I rebased. I've got an error here.

[gregtatum]

Actually that error is on master. I think it might be related to the error I mentioned above.

[jlongster]

Yep the tests are currently broken. We will fix it today.

[jlongster]

This LGTM. I think at some point we'll want to re-think our state shape, but no need to worry about it right now. Let's figure out all the various needs first.

[gregtatum]

Cool, I think have some kind of finite state machine would be more useful that flags. The memory tool has something similar.

I drew this out, but I realized that there is no way to detect the "getting next" state as far as I can tell. Observing the existing FF and Chrome debugger it looks like they don't detect the "getting next" state either.

[jasonLaster]

Thanks @TatumCreative. Looks good!

[jlongster]

@TatumCreative yeah, stepping is just "resuming" and then getting a paused packet at some later time. As we switch between paused/resumed states we update the UI. You can step from the last line of code and never get a pause packet because the code finished running, which is a valid thing to happen.

Having some kind of state flag is probably helpful though. There are various things that would be good to know about, like "paused at breakpoint", "paused on exception", etc. We'll think about this more.