[roll] Roll fuchsia [sdk][rust] Extend Rust bindings to support Mappable Clocks.

Add definitions to Rust bindings in the SDK to expose the following.

1) The new `zx_vmar_clock_map` syscall.
2) The new `zx_clock_read_mapped` syscall.
3) The new `zx_clock_get_details_mapped` syscall.
4) The new ZX_CLOCK_OPT_MAPPABLE creation flag.
5) The new `ZX_INFO_CLOCK_MAPPED_SIZE` `get_info` topic.

Note that these new definitions follow a minimalist approach to
exposing the syscalls, similar to the ones used in `libzx`.  In
particular, there is not attempt to wrap the token which comes back
from `zx_vmar_clock_map` to an object which manages the lifecycle of
the mapping and gates access to usage the token (mapping) in
`read_mapped` and `get_details` calls.

While this would generally be a Good Thing to do, the design of such
an abstraction is not without complications for at least a couple of
different reasons, including management of the lifecycle of a VMAR
handle needed to perform the unmap, as well as the expected usage of
mapped clocks in the restricted mode of Starnix where the mapping
itself needs to be borrowed over the long term (eg; not explicitly
confined to the scope of a call stack) by Restricted Mode, but cannot
be explicitly owned by Restricted Mode as Restricted Mode has no
ability to unmap the clock state at end-of-life.

So, for now, leave those abstractions to higher levels of code which
will presumably be designed to be fit-for-purpose for various specific
use cases.

Original-Bug: 374816449
Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1215126
Original-Revision: 4d3d7c8383b22d4ff39df036fe51d11fb97719a4
GitOrigin-RevId: d5d4442f23e7bb381cf83341bbda8d0c460e4504
Change-Id: I91b7b66cd4c432ae42bba8c7d1564675ca9d072d