Major updates in my fork

[jimisaacs]

First of all, I want to thank you for the amazing work that I am able to stand on the shoulders of. After making my changes to this library, I am constantly reminded, simply by reading code, of how much work, and TLC went in this.

The reason for this issue is because I wanted to make you aware of a fork that I have, where I have made significant changes to this library's infrastructure, and also incremental improvements to its logic.

A little background on the reason for this... I needed a node SAML2 implementation, and I needed one for a specific use case, to be an Identity Provider. Out of all the packages available, they all needed a little work for me to be able to use them, which included samlify. Though in the end, I chose samlify because knowing I would need to make changes to whatever package I chose, I liked samlify's API and could find my way around the architecture pretty well. This speaks to a better design, even if it needed a little work for my use case. Overall, it is just a more intuitive library compared to similar ones available for node.

So with that, I started making the changes I needed, then I noticed that I continued updating the infrastructure to the way I like packages to be now-a-days. I also continued pushing for more and more type safety. So, I stopped, backpedaled, and made these changes in a more official manner.

I will make a PR with the total scope of the changes, but here is the summary:

1. https://github.com/jimisaacs/samlify/commit/66a629cf7f6eb6381539f6fc74fdff16b32b19fb infra updates, formatting, tsconfig config, types This is by far the largest change set. It updates the entire layout of the package to be more standard in terms of node package recommendations and best practices. It does the same in terms of a typescript project. Although the formatting is mostly just cosmetic, it's worth noting that prettier is now required, tslint has changed to eslint, and vscode's "organize imports" has been run on everything and is enabled on save. There isn't much if any logic changes, except like I mentioned, the library's overall layout and API surface has. It's basically this, build/ + types/ = lib/
2. https://github.com/jimisaacs/samlify/commit/4b21aaf559fe8d14580ab252fc95f2e99fdf5a7b make customization of template processing more robust This is the reason why I forked samlify in the first place. I went all out on this one, and took the template processing in an very opinionated approach that serves my purpose, but is also very open ended where I believe if should cover many more use cases than the current approach (as of writing). I allow the custom replacement function to receive the default values, though I also went another extra mile, and expect the custom function to return both the template and the values as a tuple. Finally, the default replacement is always run last. This way any customizations happen first, and can either modify default behavior, or change it entirely.
3. https://github.com/jimisaacs/samlify/commit/583cac298cdeae67997d3568f99a9a02883ba5a5 more robust errors with SamlifyError: Pretty self explanatory here, just wanted the errors to be typed and centralized. There's a concrete error class and a error code enum.
4. https://github.com/jimisaacs/samlify/commit/e47e0a35a76d07f6496435dc35208ce3aa03feed
   cleanup types, inheritance, access, and generics: This last one was just some more cleanup really. Not much logic updates. Just internal changes to make the inheritance of classes and types easier to reason about.

With that, I will now make the PR. Let me know what you think.

Thanks again!