[FEATURE] Generate index.d.ts files, instead of index.ts files

[daogrady]

Description

So far, cds-typer generates a pair of index.js and index.ts files per namespace. While the former is required to provide runtime support and make sure entities are present and available when cds is started, the latter is meant to describe the types of the entities.

The index.ts files contain fully-fledged classes, which are sometimes picked up by the TS compiler, overwriting the accompanying index.js files with incorrect information.

Suggested Solution

Generating index.d.ts files could be an option. It would be preferable to strictly adhere to a declarative style in .d.ts files, i.e. not generate function bodies or class bodies. This can indeed be achieved. Having a pair of index.js and index.d.ts would keep tsc from compiling over the existing index.js file.

We need to investigate if this approach has any other implications in terms of importing them during runtime, them being present during build time, and using them during runtime.

Alternatives

An alternative approach would be to actually have fully usable classes in the index.ts files. So even if they are compiled into index.js files, the generated artefacts can be picked up and understood by the cds framework.
This already works in parts as of today, as we add an artificial .name property containing the fully qualified identifier into the generated classes. The cds framework, in some places, falls back to inspecting the .name property and uses that to perform a lookup in the csn.
For this to work, we'd need to make sure

(a) to really have a fully qualified .name in every generated artefact
(b) any API of the cds framework that can come into touch with cds-typer artefacts can and will perform the lookup on the .name property
(c) the additional lookup does not pose an unacceptable overhead

Additional Context

No response