Add support for multiple address blocks

[arjanmels]

SVD files allow multiple address blocks per peripheral.
This commit adds support for _add and _modify of peripherals with multiple addressblocks.
A new keyword (addressblocks) had to be introduced as YAML does not allow multiple config options with the same name. The addressblocks keyword supports a list of addressblocks.

[nickray]

Thanks :)
I'd like to wait for #15 to be merged to have a basic sanity check.
Do you have a concrete use case? In the sense that you could extend the above PR after merge to cover it?

[arjanmels]

This is for esp 32, pull request submitted (esp-rs/esp32#24).

@MabezDev, @nickray We are getting a bit into a chicken and egg situation here: this pull is needed for the esp32 pull to be functional and vice versa. How to break this deadlock?

[MabezDev]

To break the deadlock, we need to fix esp-rs/esp32#17 without breaking the stm32 builds, which is unfortunately what happened with the fix in #13

[nickray]

I just merged #15 and was hoping it would trigger a check of this PR. @arjanmels: maybe a dummy push to this PR could trigger the check? If not, could you perhaps close this PR and do a new same one?

I may be missing something, but it seems this PR is independent from the problematic #13, correct?

So I would tend to merge this PR unless the check (unexpectedly) indicates otherwise, as it's new functionality and not a change of functionality.

Long-term I feel we're accumulating a bit of cruft here (having two ways to do things seems "wrong"), but I have hope that by sharing "svdtools" across projects we surface all relevant requirements that real-life SVDs cause (with handy "regression tests") in one place, which would be a good basis for an eventual redesign/streamline/RIIR :)

[arjanmels]

@nickray Thanks for accommodating.

Dummy commit/push works to trigger Travis. The PR is indeed independent on #13.

(However the esp32 build will continue to fail, as the problem with the yaml files underlying #13 is not yet solved.)