Don’t use Promises

[Zearin]

In the spirit of Issue #8 (Don’t use EventEmitter), this PR removes Promises from microcuke.

Reasoning:

• Although Promises are not JS-specific, they are an async idea.
• Fewer people are familiar with async programming than normal/sync programming.
• Asynchronous programming styles vary wildly across libraries and languages.
• A previous comment in the source said something to the effect of, “we’re using Promises, because JavaScript. You should just return a boolean, because it’s simpler!”
  • If microcuke is supposed to a minimalist, simple-as-possible reference implementation, Promises introduce a barrier to the person reading microcuke in order to write their own implementation. (Code that would be a simple for-loop becomes a nested group of promises and anonymous function calls; a simple return value (boolean) is replaced by a more complex block of code; etc.)

The benefits of this have a lot of overlap with those of Issue #8 (removing EventEmitter):

• People who are unfamiliar with Promises or async programming will not be put off by unfamiliarity with Promises
• Easier to read and understand (even for people who do understand Promises)
• Easier to port to other languages
• When porting to other languages, someone can use their preferred async tools/constructs in their implementation
• We can add comments like, “Your implementation could use async here if desired” to encourage performance for implementations, while microcuke itself remains simple and straightforward to read and grok

[Zearin]

@aslakhellesoy ping