Transition API to return promises

[bbusschots]

ATM the API uses blocking IO, returning generated passwords directly.

Thinking ahead to possible web interface enhancements, the desired CLI interface, and uses of the library on the server side, the use of blocking IO add a barrier to the following desirable capabilities:

1. the use of external sources of randomness via a REST API (like random.org)
2. the use of external dictionaries via REST API calls, DB calls, or server-side disk IO

Before releasing the API to 1.0 it should be re-factored to return promises of passwords, and a separate function should be added to wrap the promise and deliver passwords directly. Perhaps adopt the naming conventions from NodeJS for blocking IO variants of file reads from disk etc..

Starting by just making the main function to generate passwords promise-based will have up-stream consequences, requiring other classes like those providing dictionaries and random numbers, to also move to promises.

This will be a major piece of work, and should be completed on a separate branch so as not to block work on the web interface which is progressing wonderfully on the main branch. At the very end, the web interface can be migrated over to promises when the API refactor branch is ready to be merged into the main branch.

[hepabolu]

@bbusschots Sounds like a good idea.
But I would propose that the 1.0 contains the same functionality as the Perl version of the website.
This refactoring would be 2.0 release.

[hepabolu]

BTW before we start on this issue, I'd like to get Jest + Puppeteer working first so we can test the UI better using automated tests.

[bbusschots]

@hepabolu — both of those sound good to me.

I've updated the milestone accordingly.