Typescript support and in-memory generation

#### Reason/Context
Please try answering few of those questions
- Why we need this improvement? There are a huge variety of projects using Typescript and this library offers no typings which is very necessary for those projects, for example, most of the module imports need to be via "require" instead of import
- How will this change help? We can start using import without complaints, use Generator class with static typing and IDE help and create more libraries on top of async api
- What is the motivation? Currently, i'm building a generator for Nestjs (currently there is only a package for Swagger) but for microservices, we need AsyncAPI, its being used. Nestjs is heavily used with Typescript and uses a lot of reflection to enhance the application and third-party libraries (such as swagger like i mentioned). Now regarding the in-memory generation that's something that swagger does, for the page and for its static assets instead of generating the files only. Generating the files will require OS permissions and in production that's very risky to give such, we should be able to generate to a memory buffer and simply serve from it, i think that would be beneficial instead of writing directly to FS. Also, i did nothing the template name is lazy loaded but its not cached which means that if we want to install the template as a module to generate faster we simply can't, we'll have to fetch each time our application bootstraps

#### Description
Please try answering few of those questions
- What changes have to be introduced? Generating types (https://www.typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html) and provide a new method OR option that allow us to receive a buffer containing the static assets and the page build instead of directly write using fs module
- Will this be a breaking change? No, it will just provide more enhancement
- How could it be implemented/designed? Types is pretty much straightforward and in-memory generation could be discussed but i don't think it will interfere at all with the existing codebase

No files, tests, or entry points are named. Start by mapping the existing generator, template-loading, and filesystem-generation paths, then clarify whether TypeScript typings, in-memory output, and template caching belong in one change; done should include agreed scope and tests for each requested capability.

Written by the indexing model from the issue text.