pkg/compute/pack: implement pack subcommand

[Integralist]

Problem: We want users to experiment with the C@E platform, which means being able to deploy their own WASM binaries compiled using languages not officially supported (yet).

Solution: Implement fastly compute pack, which will accept a --path to a WASM binary and will scaffold the required structure so that fastly compute deploy will know what to do.

Notes: I've also updated fastly compute init to provide a new language option of "other" as this means we can piggyback off the existing logic to build a compatible fastly.toml manifest (which fastly compute deploy will require).

Example

Start by initialising a new project (notice the messaging has changed to reflect the third option "other" being selected):

$ fastly compute init
Creating a new Compute@Edge project.

Press ^C at any time to quit.

Name: [testing-cli-packaging]
Description:
Author:
Language:
[1] Rust
[2] AssemblyScript (beta)
[3] Other (pre-compiled WASM binary)
Choose option: [1] 3

Initialized project testing-cli-packaging to:
        /Users/integralist/Code/go/testing-cli-packaging

To package a pre-compiled WASM binary for deployment, run:
        fastly compute pack

To deploy the package, run:
        fastly compute deploy

To learn about deploying Compute@Edge projects using third-party orchestration tools, visit:
        https://developer.fastly.com/learning/integrations/orchestration/

SUCCESS: Initialized project testing-cli-packaging

The only thing produced by the above subcommand run, was a valid fastly.toml.

Next, package up your pre-compiled WASM binary (in this case I reference a rust C@E starter kit I had built previously from another project):

$ fastly compute pack --path ../some/path/to/a/main.wasm && tree
✓ Initializing...
✓ Copying wasm binary...
✓ Copying manifest...
✓ Creating .tar.gz file...
.
├── fastly.toml
└── pkg
    ├── testing-cli-packaging
    │   ├── bin
    │   │   └── main.wasm
    │   └── fastly.toml
    └── testing-cli-packaging.tar.gz

3 directories, 4 files

Finally, we'll deploy this:

$ fastly compute deploy
There is no Fastly service associated with this package. To connect to an existing service
add the Service ID to the fastly.toml file, otherwise follow the prompts to create a
service now.

Press ^C at any time to quit.

Domain: [gratefully-inspired-ewe.edgecompute.app]
Backend (originless, hostname or IP address): [originless]

✓ Initializing...
✓ Creating service...
✓ Creating domain...
✓ Creating backend...
✓ Uploading package...
✓ Activating version...

Manage this service at:
        https://manage.fastly.com/configure/services/2MJOTguHXRzr7OLcnRxGTU

View this service at:
        https://gratefully-inspired-ewe.edgecompute.app

SUCCESS: Deployed package (service 2MJOTguHXRzr7OLcnRxGTU, version 1)

Fixes #174

[Integralist]

@phamann I appreciate you're busy so are you happy for someone else to review this? e.g. @fgsch

[triblondon]

"Initialized package" => "Initialized project" ?

[fgsch]

Would be possible to use a smaller binary?

[Integralist]

Would be possible to use a smaller binary?

I had used the binary compiled using https://github.com/fastly/compute-starter-kit-rust-default as I was not familiar with generating a WASM binary myself.

But I've managed to replace the main.wasm binary with a plain text file as a real binary isn't necessary for validating the tests.

[fgsch]

Tested "compute pack" deploying an existing service using an unsupported language, a supported language (rust) and also initialising a project using "Other".

Code looks and works as advertised ✔️

[fgsch]

Left a few non blocking comments but looks great to me.

Thank you for working on this!

[phamann]

Looking good - have requested some changes:

1. Question regarding an important change in terminology that has wider implications than just the CLI. Therefore, I suggest we revert for the time being,
2. Nitty ask to use the correct Wasm instead of WASM.

[phamann]

LGTM