Modernizing the strider stack

[murindwaz]

Why

Whereas some tech stack were chosen when they made sense, some are now either defunct, un-maintained, got stuck in time or check all above.

What

Non-exhaustive list of such libraries

• Bower ~ The maintainers encourage to migrate to either npm/yarn/webpack/parcel, that makes sense. Bower was a really good software, but everything bower can do, npm/yarn/webpack/parcel can do.
• $.ajax, and jQuery at large. There is fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API that is mainstream. Switching to fetch looks like another natural choice. [QUEST] Update jquery to 3.0 #1050
• Promises currently use native-or-bluebird, this used to be a good alternative, but since nodejs v8 has promises implemented, it makes sense to rely on native promises. Alternatively, native-or-bluebird page suggests to switch to any-promise
• mailcomposer since this was deprecated, a replacement with nodemailer, or any other alternative can be a good thing, before we start getting security issues. Any plans to address deprecation warnings? #1062
• Templating engine. Using the same approach would be counter-productive, especially when strider adopts SPA for its frontend code Migrating Template Engine #831

Thanks.

[knownasilya]

The client part of strider needs a rewrite, but the rest can be upgraded just fine. Feel free to submit a PR for each item.