Change execution order of FWActions

[utf]

As discussed in #407, detours and additions occur after mod_specs or update_specs are applied, meaning that any new Fireworks will not reflect the new specs.

I think it makes more sense to reverse the order of these operations because:

1. It is very confusing for new users to figure out why detours/additions do not have the modified spec (I've personally had to troubleshoot 4 separate people with this issue).
2. In the current approach, the Firetask doing the addition/detour has to know exactly what data to update in the spec at the time the Firetask is written. This often isn't known in advance and indeed the data to pass might change between workflows (which requires making a completely new Firetask just to pass different data). If the order was reversed, the Firetask doing the detour doesn't have to worry about what data is passed.

To illustrate point (1), often users try to separate the process into two Firetasks:

• The first to add the detour.
• The second to update the spec.

However, because any dynamic FWActions stop the execution of the subsequent Firetasks (this definitely needs better documentation) this approach doesn't work.