Remove user environment validation logic

[Integralist]

Context:
The compute build command currently contains internal logic for validating a user's local environment. It does this in an attempt to reduce the number of possible errors when trying to compile a Compute project.

Problem:
The validation logic is tightly coupled to specific expectations of the CLI and its starter kits and consequently results in errors that are difficult to understand and debug, as well as restricts users from using their own tools and scripts.

Solution:
We should remove as much of the user environment validation logic as possible as this will help to reduce friction for users who want to switch the tooling used, as well as reduce the general confusion caused for users when there are environment validation errors, and lastly, it reduces the maintenance overhead for contributors to the CLI code base as the logic flow becomes much simpler.

Notes:
In the 5.x CLI releases we persisted a 'default' build script to disk (specifically the fastly.toml manifest). We no longer do that as part of the changes in this PR. The intention for the new 6.0.0 CLI release is to use the default build script and inform the user but not to persist that to disk under the [scripts.build] section. This makes the developer experience less confusing for users (e.g. you no longer open up your fastly.toml manifest and find a bunch of things have been unexpectedly added/modified).

Screenshots:
Below are some screenshots to highlight the new output using the compute-starter-kit-rust-default.

First, we initialise a new project, we take a look at the fastly.toml manifest and see there is no [scripts.build] defined, and we run compute build (the CLI will use a 'default' build script known to work generally for Rust):

If we re-run the command with --verbose we'll see additional information that lets us know what the CLI is doing:

If we had instead manually updated the fastly.toml manifest to include a [scripts.build] that failed to produce the expected output (we state in our documentation that we require the build script to produce a ./bin/main.wasm binary), then we would see this error returned, which includes some generic steps to help guide the user:

The first bullet point suggestion says to re-run the command with the --verbose flag, and if we do that we'll see the following output (admittedly in my contrived example it doesn't really offer any more help but if your [scripts.build] was an actual script trying to produce a ./bin/main.wasm binary, then the output from that command would be displayed and hopefully there would be enough context in its error output to guide the user):

[kailan]

This is fantastic! Really pleased to see so much code removed. Great work