refactor: rewrite, use memcached-elasticache & drop Node 8

[aaarichter]

• [x] chore: drop Node 8 support. Min required version is Node@10.13.x
• [x] refactor(deps): remove lodash and bluebird
• [x] refactor(cache): rewrite Cache with ES6 class syntax
• [x] refactor: cache.set no longer returns a value
• [x] refactor: make inofficial cache api private
• [x] refactor: remove noop backend and make memory the default backend
• [x] fix: handle functions or promises as cache.set values as described in README.md
• [x] fix: remove deprecation message, that warned when backend name was not a string. It will throw a type error now.
• [x] deps: use memcached-elasticache instead of memcached
• [x] docs(README): update API section
• [x] chore(deps): upgrade dependencies
• [x] test: add additional test to increase test coverage

BREAKING CHANGES:

General

• Dropped Node 8.x. Use Node 10.13 or higher.
• Uses memcached-elasticache with AWS support instead of memcached. See https://github.com/jkehres/memcached-elasticache#readme
• API functions no longer support callbacks.
• API functions use native Promises instead of Bluebird.
• cached() needs to be called with a string argument as name. If the name argument is undefined, it will fallback to "default".

Cache

• Cache.setBackend() no longer returns the created backend.
• Cache.getWrapped() is removed.
• Cache backend APIs need to be promise based.
• Cache private function have been renamed.
• The following function are now private:
  • Cache.applyPrefix
  • Cache.end
  • Cache.prepareOptions
  • Cache.setBackend

cache

• cache.set(), cache.get(), cache.getOrElse(), cache.unset() no longer support the callback argument. Use them as promise.
• cache.set() no longer returns a value.
• cache.set(key, value) accepts functions and promises as value.

Backends

• Any client passed with the memcached backend options has to be an instance of Memcached.
• Backend setters no longer return a value.
• backend addType() does not return backend class anymore.

[aaarichter]

Hey @jkrems, @dbushong & @aotarola would you be so kind and have a look at this PR 😼 . Thanks

[dbushong]

If you're making breaking API changes, is there any reason to continue to support callback syntax?

Also, for the things that now return promises, you should review the README to make sure it's clear about callback use.

[dbushong]

OK, I'm thru with a quick once-over.

[aaarichter]

If you're making breaking API changes, is there any reason to continue to support callback syntax?

yes you are right, it would make sense to further simplify the code by dropping callback syntax

[aaarichter]

Hey @dbushong @aotarola

sorry it took so long to address your feedback. Would you do another review? 🙇‍♂️

I rebased and updated the PR.