Restore as a standalone operation and remove from watch

[jwthomson]

This implements @isaacabraham's suggestion in #626

[mattgallagher92]

Have you tested this when creating a new project from the template? I assume that this will break in most cases as the sln won't be called SAFE.App.sln

[jwthomson]

My belief is that the templating will replace this but I will double check and report back!

[jwthomson]

It does do the replace but for the test path I used it did the replace in such a way that the sln path's hyphens were transformed to underscores so it wouldn't work. Will dig into the templating a bit to see if I can figure out how we can avoid this.

[isaacabraham]

@Larocceau @mattgallagher92 I've just looked at this - it is not what we discussed in the review.

1. There is no need to restore the solution and then build shared.
2. We simply need to build the solution. This will implicitly restore everything.
3. The same needs to be applied when running tests - simply build the solution (which contains the test projects anyway). This will do everything required in terms of building and restoring.
4. watch run has been left without a --no-restore here - has that been tested? This looks like it'll have exactly the same issue. https://github.com/SAFE-Stack/SAFE-template/blob/master/Content/default/Build.fs#L71

I'm going to reopen #626 as this does not appear to be a 100% fix (although I'm very happy to eat humble pie and be corrected!).

[Larocceau]

@isaacabraham my bad, sorry about that!

1 & 2: Ok, I assumed doing it this way would be a bit faster. Just for my knowledge, what is the benefit of doing a full build here?
3 & 4: Fair enough! Did not think about it. Again, my bad, will be more diligent next time!

[isaacabraham]

Building the Shared project is essentially going to do the same as building the solution anyway as the shared project is referenced at the very bottom of the build chain / dependency tree, and build implicit does a restore (unless, of course, you use the --no-restore argument!).