Board definitions could already define BLUETOOTH_LFCLK_RC or not to choose
whether to use the internal RC oscillator or an external 32kHz crystal as
the source for LFCLK, but that setting was only applied when the softdevice
was enabled by ble.enable(). Apply it from the start, so that the functions
of the time module always have the specified accuracy and run without
interruption when the softdevice is enabled.

Also add an option for the third LFCLK source, synthesized from the HFCLK,
by defining BLUETOOTH_LFCLK_SYNTH.

Signed-off-by: Christian Walther <cwalther@gmx.ch>

A board that uses BLUETOOTH_LFCLK_SYNTH is expected to have a 32MHz crystal
(Do any without one exist at all? I guess not because it's required for
Bluetooth, which nRF microcontrollers are usually chosen for.), otherwise
BLUETOOTH_LFCLK_RC would be more appropriate, so start the crystal
oscillator together with LFCLK to have accurate timekeeping from the start.

Signed-off-by: Christian Walther <cwalther@gmx.ch>

Optionally adds time() and time_ns() to the time module, as well as a
machine.RTC class that only implements the datetime() method (following the
example of the rp2 port), whose sole purpose is to provide the ability to
set the time. Also provides the basis for enabling gmtime(), localtime(),
mktime() in the time module.

The nRF52 does not have a dedicated real-time clock peripheral, but
timekeeping can be done by the same real-time counter that already powers
the time.ticks_* and related functions. For reasonable accuracy, a suitable
LFCLK source is required: The internal RC oscillator (BLUETOOTH_LFCLK_RC)
by itself is insufficient, but any of the following work fine:
- external 32kHz crystal (default)
- synthesis from HFCLK (BLUETOOTH_LFCLK_SYNTH) when HFXO (external 32MHz
  crystal) is enabled
- BLUETOOTH_LFCLK_RC + periodical calibration from HFXO (automatically done
  by the SoftDevice while enabled using ble.enable())

Boards can enable this by defining both configuration options
MICROPY_PY_TIME_TICKS and MICROPY_PY_TIME_TIME_TIME_NS. Additionally, they
may want to enable MICROPY_PY_TIME_GMTIME_LOCALTIME_MKTIME.

This includes a generic implementation of mp_time_localtime_get() and
mp_time_time_get() in terms of mp_hal_time_ns(), which could also be used
by other ports. In particular by the embed port, for which I originally
wrote it, noting the following:

"I'm unsure where to put modtime_mphal.h, it could also be in extmod. The
important thing is that for MICROPY_PY_TIME_INCLUDEFILE to work it must be
at the same path in both the port build (original source tree) and the
application build (micropython_embed distribution), therefore not in
ports/embed/port.

It is named .h, mismatching the corresponding ports/*/modtime.c, because it
must not be compiled separately, which naming it .c would make harder for
users of the embed port - they would need to explicitly exclude it, whereas
this way they can continue to just compile all the .c files found in the
micropython_embed distribution except those in lib."

Signed-off-by: Christian Walther <cwalther@gmx.ch>