The floating-point precision of the target is detected (0, 30, 32 or 64)
and only those tests which can run on the target will be run.

Move hardware-specific optimizations to the very end of document, and
add visible note that it gives an example for Pyboard. Remove references
to specific hardware technologies, so the doc can be more naturally
used across ports. Various markup updates to adhere to the latest
docs conventions.

Per the latest docs conventions.

This causes `symbol` syntax to be equivalent to :any:`symbol`, which is
in turn the easiest way to cross-reference an arbitrary symbol in the
docs:

http://www.sphinx-doc.org/en/stable/markup/inline.html#role-any

:any: requires at least Sphinx 1.3 (for reference, Ubuntu 16.03 ships
with 1.3.6, the latest 1.6.3).

Any many of our docs, `symbol` is misused to specify arguments to
functions, etc. Refactoring that is in progress. (CODECONVENTIONS
already specify proper syntax for both arguments and xrefs, based
on CPython conventions).

Based on what CPython uses. However, Read The Docs theme styles this
markup in very stand-out way, so we may think what to do about it.

If for nothing else, then at least to cross-reference them.

n_args is now actually used in this function.

Instead of default 2. 3 are required to access description of individual
library modules.

At least, Sphinx 1.3.6.

This follows similar warnings in other parts of docs.

In the future, a special runner for such tests will import each test and
call test() function with an address of test server to use.

The idea is that these tests can be run with just a test server running
on a test host, with device under test connecting to it, instead of
requiring Internet connection for testing.

Such setup is however WIP, and some tests in net_hosted/ are so far
written to connect to Internet, as there're not test server written
yet. This is expected to evolve over time.

GC finalization should be enabled for modlwip, or it may lead to GC
problems with socket objects. This decreases usable heap size from
36288 to 35968 (-320) bytes.

It belongs with the other pin config functions in machine_pin.c.  Also,
esp_mphal.c is put in iRAM so this change saves about 300 bytes of iRAM
(and mp_hal_pin_open_drain is not a time critical function so doesn't
need to be in iRAM).

No changes have been made to the code, the files just moved.

These drivers can now be used by any port (so long as that port has the
_onewire driver from extmod/modonewire.c).

These drivers replace the existing 1-wire and DS18X20 drivers in the
drivers/onewire directory.  The existing ones were pyboard-specific and
not very efficient nor minimal (although the 1-wire driver was written in
pure Python it only worked at large enough CPU frequency).

This commit brings backwards incompatible API changes to the existing
1-wire drivers.  User code should be converted to use the new drivers, or
check out the old version of the code and keep a local copy (it should
continue to work unchanged).

They disable all interrupts except for SysTick and are useful for doing
certain low-level timing operations.

This follows naming scheme of other modules in extmod.

It's now generic enough to be used by any port.

The 1-wire bus is defined with fixed timings so there should be no need to
change them dynamically at runtime.  Making the timings fixed saves about
270 bytes of code and 20 bytes of RAM.

The reason it was separated is so that the low-level code could be put in
iRAM, for timing reasons.  But:

1. Tests show that it's not necessary to have this code in iRAM for it to
function correctly, and taking it out of iRAM reclaims some of that precious
resource.  Furthermore, even though these functions were in iRAM there were
some functions that it called (eg pin get/set functions) which were not in
iRAM, so partially defeated the purpose of putting the 1-wire code in iRAM.

2. It's easier to reuse this 1-wire code in other ports if it's in a single
file.

3. If it turns out that certain code does need to be in iRAM then one can
use the MP_FASTCODE macro to do that.

Previous to this patch, a label with value "0" was used to indicate an
invalid label, but that meant a wasted word (at slot 0) in the array of
label offsets.  This patch adjusts the label indices so the first one
starts at 0, and the maximum value indicates an invalid label.