async support with feature

[tommasoclini]

add async processor support using maybe_async_cfg2 on feature "async".

I tried running memory.sh and I'm getting weird results, there are 200 more bytes in every measure in every test, but when comparing actual binary size with cargo size or avr-size, the main branch and this branch are equal.
I used this command(avr-objcopy -O ihex binary.elf binary.hex) to get the raw binary, and the two files(old and new) do not differ.

[tommasoclini]

@Finomnis what do you think?

[Finomnis]

Features should enable capabilities but they should not remove them (like what you do with the original sync function)

Reason is that other libraries might enable features out of your control.

But that's a general guideline, if you say this crate is enduser specific, then maybe this might be a solution, yes.

[tari]

I agree that additiveness of features is a valid concern here. Even if one were to assume that CLI types wouldn't leak into library APIs, it's conceivable that an application would want to use both blocking and futures-based APIs in different areas. I'd prefer to make an async feature strictly add new API that's async and not replace the synchronous ones.

[tommasoclini]

Now async is separate api, by deafult the sync api is always there to be backwards compatible.
Maybe the best thing would be to have two features, sync and async, but then this would be a breaking change.
In the next breaking release to me it's best to take the approach I described.

@funbiscuit what do you think?