Reduce NullCommand nesting on the pausedCommands deque

[rlament]

While debugging another issue I noticed nesting of NullCommands. This is inefficient. The nesting means there are recursive descents for various methods.

The idiom for appending sub-commands to a command that may be a NullCommand is:
command = command.append(subcommand)

The assignment turns the append into a replace when the command is a NullCommand. When the command is guaranteed not to be NullCommand, the assignment is not necessary.

This pull request pops the top element from the deque, appends the sub-command with an assignment and then pushes it back on the deque.

On this before image note the 5 NullCommands.

After only 1 NullCommand remains.

[riverwanderer]

Tagged this PR for next release; is anything holding it back ?

[uckelman]

There aren't any tests demonstrating that behavior hasn't changed.

[rlament]

Fair enough. I've added a unit test. It is a simpler example than the captured images show. Run this test on the existing code with a breakpoint at the end. Inspecting the command variable should show two NullCommands and a DisplayCommand. Note the nesting. With the change there should be a most one NullCommand regardless of the number of commands generated by DoActionButton.