[r=gz],[bug=1208504] HPCloud: Don't incorrectly return ErrNoInstances.

Ensure that collectInstances includes servers in the missing slice if they are found but don't have an expected status. Accept BUILD(spawning) as a valid status.

So this is attempt 2 - with the knowledge that when environ.Instances()
returns ErrNoInstances we should not keep polling.

Checking the time details on the bug [1] shows that the ErrNoInstances was
returned after only 3 seconds - much shorter than the shortAttempt in
environs/openstack/provider.go. It turns out that e.collectInstances() is erronously
returning missing = [] when it finds a server, but that server doesn't have
an expected status of BUILD or ACTIV.

Moving the continue ensures that if the server is found but has the incorrect
status, it is included in the returned missing slice. I would also like to
explicitly test this change to collectInstances, but can't see a way to test
the unexposed function from environs.openstack.local_tests.go [2]. The added
test ensures simply that we do return for a BUILD(spawning) server.

Testing the `juju -v bootstrap && juju -v status` 10 times showed that
HPClound would get to BUILD(spawning) in around 9.1 seconds, so I've
increased the shortTimeout slightly to 15. Let me know if you prefer
something smaller.

Other things I tried:
 * Avoiding the increased shortAttempt by checking for:
      strings.HasPrefix(server.Status, nova.StatusBuild)
   Testing shows that HPCloud returns not "BUILD", but rather
   "BUILD(networking)" and "BUILD(spawning)" [4]. But this had one main issue
   in that we'd return with BUILD(networking) which is before the server has
   a public IP address.

[1] https://bugs.launchpad.net/juju-core/+bug/1208504
[2] http://paste.ubuntu.com/6002418/
[3] http://paste.ubuntu.com/5988133/
[4] See http://docs.hpcloud.com/api/compute#ServerStates (past where it states
the possible values :-))

https://codereview.appspot.com/12795045/