Respect the declared/returned type of data type rules, which is relevant for the default value converter

[JohannesMeierSE]

This PR contributes:

• fix to respect the declared/returned type of data type rules, when (among others) checked by the default value converter
• test cases for the default value converter, when using data type rules with declared return type which use terminal rules

This issue was found in a real-world application, where a data type rule (with returns number) which referred to a terminal rule (with returns number) produced a string value at runtime in the AST (while the generated property in the TypeScript interface had the correct type number). This conforms to the "number case" in the new test case. The cases for string and boolean are added only to be more complete.

This issue is not related to #1478.

[msujew]

Looking at the lint CI, it seems like the change leads to a regression. The generated names actually change from the data type name to their declared types. I'm suprised we don't have actual tests for that. Do you mind adding some?

As for the change, I would recommend something else:

1. Create a new getRuleTypeName function that reuses the old behavior of the getRuleType function. It should be used everywhere except for the ValueConverter.
2. Add appropriate comments to explain the difference between those two functions. getRuleType should be used during the runtime, while getRuleTypeName is useful for code generation and the internal type system.

[JohannesMeierSE]

Thanks @msujew for your review! I created two functions, one to be used at runtime and the other one at development time.

However, there are already test cases which check the generated code for data type rules with return type:
https://github.com/eclipse-langium/langium/blob/main/packages/langium-cli/test/generator/ast-generator.test.ts#L170
But I don't understand, why they didn't show the regression.

Any ideas?

[msujew]

@JohannesMeierSE These tests don't test the generated property types. For example:

Value: id=ID;
ID returns string: ...;

is supposed to generate:

export interface Value extends AstNode {
  id: ID // <-- this is the part that broke
}
export type ID = string;

[JohannesMeierSE]

Thanks for the suggestion @msujew! I added two test cases which test properties with data types which have an explicit return type.

[msujew]

Looks good to me 👍