Make waasabi-init more goal-oriented to better cater for varying usecases

[flaki]

Currently waasabi-init doesn't cater well for different use cases. Here are some examples:

• Trying out Waasabi by spinning up a server on the local machine
• Developing the various parts of the Waasabi framework
• Configuring an instance for cloud/server deployment

All of the above goals have a strong impact on how waasabi-init should create the instance. For example, for local development it would be useful to start the backend in development mode (#2), or have local folders mounted into the instance for easy access from an IDE (#6). When building for cloud deployment, on the other hand, we don't care about Ngrok, and we want to re-enable generating a secure Let'sEncrypt certificate — something we disable in local instances, as Ngrok takes care of this.

For these reasons we should think about how to best expose these differences between the various usecases for waasabi-init and treat them accordingly.

One idea here is to create "profiles", and associate them with a selection offered as a first thing to the user. These profiles would configure waasabi-init itself, by enabling and/or disabling certain paths / questions.

[flaki]

This improved greatly by #13 landing, at least from the flow side, still needs implementation of the non-launch usecase.