This avoids a crash when the Deno process has been running for
2**32 ms (about 50 days). Additionaly, time complexity of finding which
timer is due to fire next is reduced from from O(n) to O(log n).

When the global timer fires earlier than expected, which apparently
happens sometimes on server editions of Windows, we didn't call any
setTimeout callbacks, but we *also* didn't reschedule the global timer
to fire again later.

When this situation occurred it would make deno exit abruptly if there
were no other asynchronous ops running on the event loop. It could also
lead to application hangs if the upcoming setTimeout callback was
critical for the application to make progress.

Instead of using core/snapshot_creator.rs, instead two crates are
introduced which allow building the snapshot during build.rs.

Rollup is removed and replaced with our own bundler. This removes
the Node build dependency. Modules in //js now use Deno-style imports
with file extensions, rather than Node style extensionless imports.

This improves incremental build time when changes are made to //js files
by about 40 seconds.

* Revert "port more ops to JSON (#2809)"

This reverts commit 137f3373.

* Revert "port ops to JSON: compiler, errors, fetch, files (#2804)"

This reverts commit 79f82cf1.

* Revert "Port rest of os ops to JSON (#2802)"

This reverts commit 5b2baa5c.

Just some clean up reorganization around flatbuffer/minimal dispatch
code. This is prep for adding a JSON dispatcher.

Fixes some sed errors introduced in c43cfe.

Unfortunately moving libdeno required splitting build.rs into two parts,
one for cli and one for core.

I've also removed the arm64 build - it's complicating things at this
re-org and we're not even testing it. I need to swing back to it and get
tools/test.py running for it.

This is in preperation for core integration.

This better disambiguates with the msg_generated.ts module, which in JS
we call "fbs", but would be better called "msg".

To be used for a timers implementation soon.

And send() -> sendSync()

Refactors handlers.rs

The idea is that all Deno "ops" (aka bindings) should map onto
a Rust Future. By setting the "sync" flag in the Base message
users can determine if the future is executed immediately or put
on the event loop.

In the case of async futures, a promise is automatically created.
Errors are automatically forwarded and raised.

TODO:

- The file system ops in src/handler.rs are not using the thread pool
  yet. This will be done in the future using tokio_threadpool::blocking.
  That is, if you try to call them asynchronously, you will get a promise
  and it will act asynchronous, but currently it will be blocking.
- Handlers in src/handler.rs returned boxed futures. This was to make
  it easy while developing. We should try to remove this allocation.

Also removes assignCmdId as it's currently unused.