stm32f1: Resurrect DMA support. (sets up breaking change)

Breaking change set up: struct dma_handler_config is no longer part of
the public API in <libmaple/dma.h>. User code which was touching
these was always mistaken; it should be using dma_attach_interrupt()
or dma_detach_interrupt() instead.

Other than that, just move the nonportable bits in <libmaple/dma.h>
and libmaple/dma.c to the appropriate places under
libmaple/stm32f1/. (Ouch. This is almost everything.) Patch the
(new) STM32F1 <series/dma.h> here and there to make everything
compile; this is mostly limited to forward-declaring struct dma_dev
and providing a hack _dma_dev_regs() declaration so inline functions
in the series header can still access a device's registers.

Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
STM32F1: adc: Tweaks for XL-density MCUs.

Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
stm32f1/adc.c: Cosmetics.

Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
stm32f1/adc.h: Add missing includes.

Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
libmaple/adc.h: Cosmetics.

Add "extern" to mark portable interface routines that are implemented
individually by each series.

Move some code around.

Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
[UNTESTED] Add new "tube"-based DMA interface.

***NEW DMA INTERFACE***. Needs testing and experimentation in a
variety of common use cases before we commit to it.

STM32F1 conducts DMAed bytes through channels 1--7. STM32F2 conducts
them through streams, where stream listens to one of channels 0--7.
There is otherwise a close correspondence between channels and
streams: each is configured with a peripheral and memory address, a
number of data to transfer, and other settings (memory/peripheral
address post-increment, etc.). The STM32F2 versions are more
general (supporting double buffering and FIFOs, etc.), but otherwise
there is a direct analogy beween channels on F1 and streams on F2 (the
fact that F2 reused the word "channels" to describe what streams
listen to is confusing and unfortunate).

To help present a simple abstraction, we introduce the type
"dma_tube", which stands for whatever you configure to set up a DMA
transfer. On STM32F1, a dma_tube is a dma_channel. On STM32F2, it will
be a dma_stream. You can configure a dma_tube using the function
dma_tube_cfg(), which each series must implement.

This abstraction (along with some others, notably dma_request_src and
dma_mode_flags, described in comments in the patch to
<libmaple/dma.h>) lets us make a DMA interface that will hopefully
help portability between the two series. It's true that code using DMA
is, in the end, nonportable, but large chunks of it can be abstracted
out, with the nonportable bits hopefully mostly relegated to data
rather than code.

Implement this new abstraction on F1, keeping the old names (which use
"channel" instead of "tube") around for backwards compatibility. Also
update for XL-density and fix some DMA2 CH4/CH5 bugs we've had lying
around for a while. (This really belongs in another commit...).

Add <libmaple/dma_common.h> for things that <libmaple/dma.h> and
<series/dma.h> both need. This prevents us from putting things into
the libmaple header, then including the series header, which is an
ugly hack we've used elsewhere and should retroactively fix.

Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>