[compiler.h] Migrate many C++ clients of countof to fbl::count_of

The latter is safer in C++, and the former is a namespace violation in
compiler.h that eventually needs to be resolved.

Test: CQ; should be no functional change
Change-Id: I9809b9fe062fd5f07226323035bf094b3f9de798

[zx] Fix typing of zx::object:get_child() out-parameter.

- Add specializations of get_child() with correct out-parameter types under
zx::process, zx::job, etc.
- Update zx::object::get_child() to emit a generic zx::handle, to make caller
assumptions as to the returned type more explicit in calling code.
- Fix crashsvc to use job, process and thread wrappers rather than generic
handle wrapper.

Bug: ZX-2310
TEST=libzx-test

Change-Id: Ifa934a39de95b52c93d930538cc532dcefa3379a

[syscalls] zx_channel_write should always consume handles

Previously, whether zx_channel_write consumed handles depended on
whether it succeeded or failed.

ZX-2204 #comment

Test: utest/core/channel
Change-Id: Ie44a8e101fa5e7d0cefc1e1e65cfd084640aa54f

[musl] Rename zx_get_startup_handle to zx_take_startup_handle

The new name more clearly describes the ownership semantics.

ZX-2235 #comment

Change-Id: I887c1f2ad657e3aff9716b9f1865184cb8cf05f7

[syscalls] Remove count arguments from port_queue and port_wait

This argument is not used and always must be one. I tried implementing
some reasonable behavior for this parameter on port_queue, but it wasn't
clear what to do when we encounter an error during the queue operation
because there isn't an out parameter for how many we succeeded in
queuing.

Rather than having a half-baked feature, we should just remove the
parameter and add another function that does vectorized versions of
these operations if we need that in the future.

Change-Id: Ifffcd6d705442cc830912a67c8117ffe5ec8295d

[debug][devmgr] Create crashsvc as system-level exception handler

crashsvc listens on the root job's exception port and dispatches to
back to devmgr to have it deal with the exception. devmgr in turn
launches an analyzer process to do something with the process that
sustained the exception. This is to allow for customization of the
exception handler, rather than always having crashlogger handle
exceptions. Short doc on rationale at go/crashsvc.

For the time being however, a refactored crashlogger (named
crashanalyzer) is still always used as the analyzer. Followups will
allow for customization of the analyzer.

crashanalyzer is a stripped down copy of crashlogger. For the time being
an #ifdef ENABLE_CRASHLOGGER is available in devmgr for easy switching
on/off, to restore the previous behaviour of registering crashlogger as
the exception handler on the root job.

Change-Id: Id10c52c2a31a5ccfeed9b63eb794559c77592df8