Rework driver integration with proper typings

[ViraVnh]

Right now I'm taking a lot of shortcuts by using "any" whenever I know the object will go through without issue but the types miss-match. I don't know if I'm doomed for it to happen because i built my own schema types or if there's a way to have the native and custom types play nice together.

[ViraVnh]

Alright there are a couple things that need to happen:

• Defining the query structure.
• Simplify the typings
• Decouple the glase layer from the native mongodb driver (in order for glase to support other drivers).

I realize most of my projects use either objectids or unique keys for queries. It's coming from an old habit but I guess it makes sense to prioritize requests made based on indexes (specially in nosql databases). So I'd say for a first version I could focus on providing query support only on T.ObjectId or unique fields, which would quickly ease the writing of typings for those. Then support for more complex queries would come when needed, but still be accessible in the mean-time through direct access to the native driver.

[ViraVnh]

It took some wrapping around but I think I have a potential target solution. I pretty much dumped away most of the previous code and acted the decoupling right away. This forces me to prepare abstract classes and generic things so that drivers can be easily written, which in turn should contribute to the simpler types.

I've setup a type transformation map which allow each driver to easily declare its own database specific types and the methods needed to convert to and from my native glase types, so now I have two generic method that I can use easily in my document interactions.

[ViraVnh]

Back from weekend~ Merged the base decoupling with 5e27345bcd97bd2f2231ea7c2e7b3e3f59901b35 . I also added the base query typing idea but with no method implementation yet, I still have to make up my mind about it (I think it will be a base Partial doc search + Query Builder + Raw otherwise).

I really like the current structure but I'd love to be able to completely skip database.server.ts (in app/). App is supposed to show what people actually have to write, and the goal is to reduce that as much as possible. I guess that if I add a bigger wrapper for the App, I'll be able to just have a big root.server.ts file where people essentially load their drivers and extensions. Eventually that file could be generated from a configuration file.

The strength of the current driver structure is that devs can still access drivers with proper typings if glase lacks some features, although the goal is to have enough stuff and a unified framework so that you can swap drivers without having to think about it. (at least as long as you don't migrate db......)

[ViraVnh]

So I procrastinated and instead of working on the model's queries, I went and did the whole internal modules' structuration, and added (and fixed three times...) the type inference. I still don't like how my base app file (the root index.ts file) has to be generic and know about each module's driver types, but after a few tries at breaking typescript to have it infer without generics I gave up (although I know there was a way a few years ago to do it, but it's just very niche).

The takeaway in all that is I now have an entry point for Glase through the Config method, which the base server drivers will call to setup the app and receive all the utility methods. I also now have a unified entry point for the config, which means I can easily throw it in its own file.