Bug 1038630 - Split Tutorial init into init, begin methods.

* init early in FTU, call begin from 'Get started' button
Separating the initialization (mostly loading config) and actual playing of the tutorial. The conflation of those two was the cause of this bug as we were calling init() twice. 

* Dont wait to loadConfig in ftu AppManager

We werent getting any real value from waiting for loadConfig and testing if the stepsKey was defined in the config, so I removed that for now. I think in the future we might want to have a point release where we have nothing new to show the user to we might want to rework that at that time. 

* Add 1.3..2.1 and 1.4..2.1 upgrade steps to facilitate meaningful manual testing on master

We'll have new 2.0..2.1 tutorial content at some point, but as it is not yet defined, there's no entry here. Likewise for 1.3 and 1.4 to 2.1 upgrades - I'm just reusing the 2.0 content for now. 

When we uplift for 2.0, it might make sense to omit these changes (though they don't do any harm)
would it make more sense to divide this in pure versions, and get the needed steps depending on the current version? 
```javascript
{
  '1.3': {
  ...
  },
  '1.4': {
  ...
  },
  '2.0': {
  ...
  }
}
```

and push only the values between `previousOS` and `currentOS` to a `var stepsToShow`that we will play with

Of course this can be done on for future bug, as this is 2.0+ and I don't want to block on this, just thinking out loud.