I want to develop single-module wrappers by default, and not be constrained/guided by "Query" or "Mutation" notions

[namesty]

Description

Previously #835

Today, users are restricted to programming their wrapper's logic into 2 different Wasm modules: query.wasm and mutation.wasm This is because in the schema interface layer, we are abiding by standard GraphQL best practices, and exposing all executable methods via the Query and Mutation types.

Based on prior considerations, we are moving farther away from GraphQL (more information here), so it only makes sense to also allow developers to name their own custom modules.

And not only that, because of this GraphQL notion, we've been assuming wrappers to contain multiple modules by default; when this is not the regular case with regular libraries and SDKs. Working with an arbitrary number of named modules inside of a wrapper, comes with a non-trivial increase in complexity and capability, just like working with a monorepo.

Therefore, we should assume single-module wrappers as the default case. We would develop additional, multiple module specific, infrastructure in the future

Planning

After a conversation with @dOrgJelli and later with @cbrzn, we agreed on removing the concept of modules in the current implementation altogether; and in the future, if needed, re-add it with a different implementation and mindset completely.

This would not only simplify the complexity around the core parts of the toolchain, but also simplify the development, usage and invocation of wrappers in general.

A summary of the conversation can be found here

Implementation Plan

A safe way of implementing the necessary changes in parallel without much conflict would be separating the changes related to the schema pipeline, from the rest of the core infrastructure's changes. Hence, the necessary subtasks are:

• Remove modules infrastructure from the CLI, Client and Core #887
• Remove modules infrastructure from the Schema Pipeline #888
• Update plugins to not use Query or Mutation modules #889
• Update demos, so that they don't use Query/Mutation modules #890
• Update docs post-single-module refactor #919

[cbrzn]

Note that templates packages need to be updated too - Is it worth creating a subtask for this?