Upstream types from query-client and use a new magic type for deep casting

[spaenleh]

This PR adds a frontend entry-point that exposes the types used by the frontends (derived from backend types with immutable sugar coating).

closes #74

[pyphilia]

Amazing work thank you, this change will definitively improve our whole codebase, and I hope it will also improve the frontend's build problems 😍

[spaenleh]

An issue I have when using the ImmutableCast is that the resulting type alias is evaluated to any... This is a problem. I will try to check if using a typing function could work better in this case.

[spaenleh]

The issue I faced with types resolving to any was linked to path aliases no beeing resolved to relative urls after transpilation. This was resolved by using tsc-alias and changing the build command to tsc && tsc-alias 😄

[codeofmochi]

Overall LGTM 🦖 Thank you for your work! I think it's really nice to let the type system do the heavy lifting instead of writing boilerplate code and having weird casts 😄

I've left a bunch of comments, let me know what you think or if you have any question. Not all of them require changes, feel free to decide on what's relevant

[codeofmochi]

Very cool, I didn't know that T and immutable.Record<T> would resolve to the same value type when using the same property access pattern (though it makes sense) 😅

[spaenleh]

Actually it allows the use of this method in immutable and non-immutable world, with the output being immutable when the input was and vice-versa (not sure it was what you meant 😄 ). This was allowed by the work that we did to be able to access properties of records without the .get() method (still a mystery to me to this day).