More comprehensive templates option

[itowlson]

We have a tension in the template system between those who want the generate code to give users a clear roadmap to all the things and those who were extremely burned by 2010s Microsoft project templates that gave you 44 files of an entire working N-tier application that you had to spend half a day deleting code out of to get it back to a point where-- uh anyway some of us were cautious about overdoing it.

This PR explores offering a command line flag on new/add which is passed through to the template and can be used by the template to add optional fields, comments, links, etc. that may feel like clutter to some but provide helpful pointers to others. The flag is currently called --explain and is defaulted to false: both of these are up for grabs (in particular, the default means that users need to know that the flag exists to get the extra stuff, which may well be perverse).

Another possible approach is, instead of making it a system-level flag, have it as a parameter within each template, where it could be prompted for. This avoids the need for new users to know about the magic flag. But having it at system level opens the door to adding more guidance outside of template execution, e.g. displaying instructions on how to run spin build and spin up. (A future thing could also allow for displaying template-specific guidance e.g. "you'll need Rust 1.99 and the wasm32-wasip7 target, here's how to get them.")

The PR currently updates just one template, ye olde http-rust. If we decide we want to do this, and once we are aligned on the approach, it should be easy to update others.

Sample generated manifest from spin new http-rust explain-test -a --explain:

spin_manifest_version = 2

[application]
name = "explain-test"
version = "0.1.0"
authors = ["itowlson <[email protected]>"]
description = ""

[[trigger.http]]
route = "/..."
component = "explain-test"

[component.explain-test]
source = "target/wasm32-wasip1/release/explain_test.wasm"
# The network hosts to which the component may make requests to. E.g. ["https://example.com", "postgres://data.example.com:4004"]
# Learn more: https://spinframework.dev/v3/http-outbound#granting-http-permissions-to-components, https://spinframework.dev/v3/mqtt-outbound#granting-network-permissions-to-components, https://spinframework.dev/v3/rdbms-storage#granting-network-permissions-to-components
allowed_outbound_hosts = []
# The files from your host system that should be included in the application and available to the component. E.g. [{ source = "assets", destination = "/"}]
# Learn more: https://spinframework.dev/v3/writing-apps#including-files-with-components
files = []
# The key-value stores the component should have access to. E.g. ["default", "cache"]. Learn more: https://spinframework.dev/v3/kv-store-api-guide#granting-key-value-store-permissions-to-components
# Non-default stores must be mapped in a runtime config file. Learn more: https://spinframework.dev/v3/dynamic-configuration#key-value-store-runtime-configuration
key_value_stores = []
# The SQLite databases the component should have access to. E.g. ["default", "accounts"]. Learn more: https://spinframework.dev/v3/sqlite-api-guide#granting-sqlite-database-permissions-to-components
# Non-default databases must be mapped in a runtime config file. Learn more: hhttps://spinframework.dev/v3/dynamic-configuration#sqlite-storage-runtime-configuration
sqlite_databases = []

[component.explain-test.dependencies]
# Wasm components on which your Wasm binary depends. Learn more: https://spinframework.dev/v3/writing-apps#using-component-dependencies

[component.explain-test.build]
command = "cargo build --target wasm32-wasip1 --release"
watch = ["src/**/*.rs", "Cargo.toml"]

(Draft for now because if we go forward there will be more to do on other templates.)

[itowlson]

Context: #2874