Adds features to specify stm32f103xx flash density

[davidtibbetts]

Stm32f103xx MCUs come in different flash densities, which affects the
FLASH and RAM specified in memory.x. This change adds features to this
board support package to be able to specify which flash density you
wish to target. This relates to, but does not directly fix, issue #37.

[davidtibbetts]

I just wanted to mention that this was the best solution I found to specify memory layouts at compile-time. Building an example now requires --features stm32f103x_ to be specified, otherwise no memory file will be found due to conditional compiling in build.rs.

I can update the README and documentation, if needed, in this PR.

[lnicola]

It feels a bit weird. Maybe a configuration would be better?

Another approach I've seen is defining features like min_6_kb_ram, min_10_kb_ram, min_20_kb_ram, min_16_kb_flash and so on.

[davidtibbetts]

Agreed, it feels weird, but was the best way I could do it user-friendly at the moment.
I attempted using a configuration, but because of the cross-compiling(?), the rustflags don't get passed to the build.rs. I'm guessing it has something to do with this issue: rust-lang/cargo#4423
I'll take another stab at using non-feature configuration, but may require adding to the .cargo/config where rustflags is specified on the targets in order to be able to pass --cfg flash=stm32f103xB to rustc.

[therealprof]

@gbip I'm not a big fan of this approach. The memory configuration should always be on a per application basis because you might want to have RAM/Flash excluded for specific uses or restrict to a specific size. I think the only reason for the memory.x to be in that crate is so the examples can be compiled.

[burrbull]

cargo generate now supports git branches
We could create branches in cortex-m-quickstart for most prevalent micros.