Increase return code repertoire

**What are you trying to do?**
Many multipass commands can timeout while completing, returning an error return code (2 or 5, see additional context). While some timeouts are not recoverable (timeout during the ssh section of `launch`ing a vm will require a `stop --force` or a `delete`), other timeouts are entirely recoverable and may even result in an eventual success (timeout during `cloud-init` section of `launch`). They are currently impossible to tell apart from the return codes alone or from output messages.

**What's your proposed solution?**
Draft a return code convention and apply it to timeouts. Timeout errors should be distinguished from regular errors, and certain timeouts that could have resulted in success should be distinguished from those that cannot be recovered or were certainly failures.

No-ops should have return codes that reflect the state of the vm: if `suspend` on a `stop`ed instance, the return code is 0 because `start` works/behaves as expected on a `suspend`ed instance.

Other possible exit states should also have their own distinct codes, if they exist, in a similar manner to the proposed one.

**Additional context**
Additionally it seems the return code from a default timeout and a `--timeout` that is specified are different (2 vs. 5). They should be the same as well.

Start by reviewing the return-code handling for the multipass commands and timeout paths described, especially launch, stop, delete, and suspend. Compare default and explicitly supplied timeouts, then document the proposed distinctions and verify that each command reports the intended VM state consistently.

Written by the indexing model from the issue text.