rust_doc: add web server for docs

[wchargin]

A rust_doc rule emits its output into a zip archive so that the build
graph can be statically known, but this makes it hard to actually view
the documentation. This patch adds a rust_doc_server macro, a sibling
to rust_doc that spins up a tiny web server that reads from the zip
file. The server can run under ibazel and automatically restart when
the documentation sources are updated.

This is written in Python for a simple cross-platform solution that
doesn’t require compiling a Rust web stack, which takes about 20 seconds
on my workstation (Xeon W-2135).

Fixes #472.

Test Plan:
From examples/, run bazel run //hello_world:hello_world_doc_server
and note that the server responds properly. Run with -- --port 0
(extra -- for bazel run) and note that the server properly prints
its actual port.

wchargin-branch: rustdoc-server

[wchargin]

This PR’s diffbase is the #474 branch, so please ignore the extraneous
changes (you can look at just a subset of the commits).

Opening this to get @dfreese’s opinion re: Python usage, per discussion
on #474. If the direction looks good to you, I’ll flesh out docs/polish.
(edit: added minimal docs to make CI happy).

Thanks! Happy to incorporate any feedback.

[dfreese]

From a high level design perspective, do we want to be generating a server target for every rustdoc target, or just a single binary target that serves as a tool that can handle any rustdoc output?

[wchargin]

From a high level design perspective, do we want to be generating a server target for every rustdoc target, or just a single binary target that serves as a tool that can handle any rustdoc output?

If you want to be able to ibazel run it and have the server
automatically restart when the Rust code is updated, there needs to be a
build path from the target that you run to your code, so I think that
there needs to be a server target for each rustdoc target. Now, these
could be trivial shims that just delegate to a single core server, but
given that they’re just Python files it seems easier to just let each
one be its own self-contained server. I don’t feel strongly about this.

On the build side, I’m having trouble getting the docs sub-repo to work
with rules_python without crashing the build. So I’m feeling inclined
to abandon this. On TensorBoard, we just have our own version of this
server as a local py_binary, so I’m not personally blocked by this.
If anyone happens to know an easy fix for the build issue, I’d be happy
to incorporate it, or if you want to poke at it yourself, please feel
free to yoink my server code.

@dfreese, does this sound reasonable to you?