spin new -E should not fail just because template update fails

[itowlson]

spin new -E always tries to install the latest templates from the remote. If this fails, spin new bails.

But this is suboptimal for people doing spin new -E on a plane or whatever. If they've already got templates for their environment, they should be allowed to use those: okay, they might not be the latest, but 1. they probably are and 2. even if they're not, they're still better than nothing.

This fixes that. As long as they have templates for the env, they'll be able to create apps even while away from the network.

(Obviously, if they have never had the templates at all before getting on the plane, they're still out of luck. Fixing this is outside the scope of Spin.)

Tested by new -E-ing from a local env file, then modifying the env file to point to an invalid tag and new -E-ing again. Got the "can't check" warning but it still let me use the templates.

Reviewer notes:

• I am not sure what to do about the code structure here. The function is now nearly 100 lines, with multiple conditionals and significant nesting, and arms pushed more than a screen apart so you see a case and go "wait what does this go with". I tried extracting functions to do the env template install and manage the if-then logic (e.g. return an outcome code and drive messaging off that( but nothing came out very nicely. Advice welcome!

• I wondered if I should put a timeout on it so the user of a ropey network doesn't get blocked waiting for a network connection that will never come. It's a nice backstop but man even moar complexity? Yikes. Thoughts?

[vdice]

LGTM. I'd guess you're likely to have the most critical eye towards code structure; I'm not too worried. Timeout: perhaps, at some point... but don't think it is a pressing need. (Probably other spots in Spin code where it might apply? A holistic helper func/pkg might be the way to go.)