Make body!() and content!() synchronous.

[NHDaly]

Adds an option, async to body!() and content!(), which when true will
give the old behavior (return immediately), but when false, will block until
the Window is finished evaling the javascript statement to assign the new content.

Note that this blocks until evalscripts has been called for all new scripts,
but that if your scripts themselves do anything asynchronous, it won't wait for
them to finish.

---

Right now, I have async=true by default so that this doesn't change the
current behavior, but I really think we should set this false by default! :) If
you want, we can merge it in like this, wait for it to soak in, make sure
everyone likes the change, etc, and then flip the switch?

That said, it shouldn't break anyone's code to just flip the default, it will
just likely make it a bit slower.

Part of fixing #108.

[NHDaly]

A couple questions:

1. The only remaining content api that doesn't have an async option is loadcss!. Can we simply change that to use @js instead of @js_?
2. Before this PR, content! called @js_, which returns the Page it's called with. I guess this could be useful for chaining? (e.g. content!(content!(w, "#a", "x"), "#b", "y")), but idk why you'd do that..
   So for this PR, I kept it that way, even in the async version. Do you think that makes sense, or is it better to return something like true showing it succeeded or something?

[NHDaly]

After this, I think the only remaining major API that doesn't have a synchronous option is opening a Window. It's annoying that that isn't synchronous as well, so i'd like to tackle that too, but it'll have to be a different PR. :)

[NHDaly]

Friendly ping. This passes all tests. Is there any objection to me just merging this in? :]

[pfitzseb]

LGTM.

[NHDaly]

Cool, thanks a bunch! :)

[pfitzseb]

Thanks for the PR! :)

[NHDaly]

:) No problem!

Also, i've just realized it's worth noting that I left async=true as the default, so this doesn't change anything by default. Users have to manually pass async=false to get the synchronous behavior.

That said, I think probably false should be the default, since A) it's almost always probably what you want, and B) that matches most normal julia functions, which are synchronous by default.

I think probably the best way to proceed is after also checking-in #137, we have a single PR that flips the defaults. I think probably that should happen with a version bump, though, since it changes behavior. Does that sound right to you? :)