docs: Type-safe code generated interface for future calls

[Crazelu]

Adds documentation for the type-safe code generated interface for future calls

[Crazelu]

@marcelomendoncasoares here's the PR for the future calls docs

[marcelomendoncasoares]

Thanks for the quick PR on the docs, @Crazelu! I have left a few guidelines about the experience we aim with docs on the comments, and also some improvement/fixes suggestions.

Beyond these, I missed a reference on the usage of abstract to declare future calls in modules, that users can extend in their own projects - since there is no way for users to mixture the ones generated in the module with their own. We should also present the support for inheritance of future calls in itself.

Another extra page that is worth adding is Recurring tasks to show how to achieve a cron-like scheduling. The current recommended way is by scheduling a future call inside another - at the start, for example. With generated future calls, though, it will probably be a two step operation or require the creation of two separate future calls: one for the unit execution, the other for invoking the first twice (now and next) to make it recurrent.

[marcelomendoncasoares]

Suggestion: Unrelated change, but it is worth for future calls (and only valid now with a recent PR).

Suggested change

	3. __Avoid changing or removing fields and types in the serialized classes.__ However, you are free to add new fields as long as they are nullable.
	4. __Avoid changing parameter names in future call methods.__ Changing the parameter names of the future call methods will break backward compatibility since parameters are passed by name.
	3. __Avoid changing or removing fields and types in the serialized classes.__ However, you are free to add new fields as long as they are nullable or have a default value.
	4. __Avoid changing parameter names in future call methods.__ Changing the parameter names of the future call methods will break backward compatibility since parameters are passed by name.

[marcelomendoncasoares]

The experience we want to provide with the docs is for users to receive as little context as they need to get started with a given feature, then be redirected to dedicated pages as needed to get deeper in details or more advanced scenarios. The "Working with Endpoints" and "Working with Models" pages are not examples here, because they are presenting everything at once and have a refactor pending. Take an inspiration on how we did the Authentication and each Provider under it.

Future calls are different from authentication, though, because they require no setup to work - as with models and endpoints. Although there is the possibility to configure, this is optional and should be shown separately.

This overview page should start with the general context (as it has now) and proceed guiding the user on how to create a simple FutureCall. Think of this first page more like a guide than a documentation. Then, all details that could be mentioned along the way can be noted in infos/tips/notes that point to the more advanced page.

It is worth mentioning in the feature presentation as it being the same experience as endpoints, but for scheduling future work.

[marcelomendoncasoares]

It is best that the first examples are fully complete snippets that can be copy/pasted and work (or nearly due to the name of the project that goes in the imports). See the example below from authentication:

serverpod_docs/docs/06-concepts/11-authentication/01-setup.md

Lines 29 to 61 in 4367b7e

	```dart
	import 'package:serverpod/serverpod.dart';
	import 'package:serverpod_auth_idp_server/core.dart';
	import 'src/generated/protocol.dart';
	import 'src/generated/endpoints.dart';
	void run(List<String> args) async {
	final pod = Serverpod(
	args,
	Protocol(),
	Endpoints(),
	);
	// Set up authentication services
	// The `pod.getPassword()` will get the value from `config/passwords.yaml`.
	pod.initializeAuthServices(
	tokenManagerBuilders: [
	JwtConfig(
	// Pepper used to hash the refresh token secret.
	refreshTokenHashPepper: pod.getPassword('jwtRefreshTokenHashPepper')!,
	// Algorithm used to sign the tokens (`hmacSha512` or `ecdsaSha512`).
	algorithm: JwtAlgorithm.hmacSha512(
	// Private key to sign the tokens. Must be a valid HMAC SHA-512 key.
	SecretKey(pod.getPassword('jwtHmacSha512PrivateKey')!),
	)
	),
	],
	);
	await pod.start();
	}
	```

[marcelomendoncasoares]

It is no longer necessary to cd into the server to run generate.

Suggested change

	Next, you need to generate the code for your future calls. You do this by running `serverpod generate` in the server directory of your project:
	```bash
	$ cd your_server
	$ serverpod generate
	```
	`serverpod generate` will create a type-safe interface for invoking the future calls in the server's `generated/future_calls.dart` file. This interface can be accessed from the Serverpod object.
	Next, you need to generate the code for your future calls:
	\```bash
	$ serverpod generate
	\```
	Running generate will create a type-safe interface for invoking the future calls in the server's `generated/future_calls.dart` file. This interface can be accessed from the Serverpod object through the `pod.futureCalls` getter.

Ignore the backslash before the ``` markers. This is just to avoid breaking the suggestion.

[marcelomendoncasoares]

It is worth explaining why is this format legacy and in favor of what has it is been discontinued - citing the need for manual registration and the error-prone management of future calls by string names. It is good to have a warning pointing to the overview as the new recommended experience to highlight this.

[marcelomendoncasoares]

This is no longer true: methods can now have an arbitrary number of parameters, including only the session, right? We should also mention here that Streaming parameters are not supported.

[marcelomendoncasoares]

Just to broaden the examples, it could be good to have two methods here and show one with callAtTime and the other with callWithDelay below.

[marcelomendoncasoares]

It is worth enforcing with a warning that trying to schedule future calls before server start will lead to exceptions.