add PwmPin mock

[rursprung]

this extends the Pin::Mock to also cover the PwmPin trait.

some observations on this commit:

• i took the liberty of just hardcoding the PwmPin::Duty to be an
  u16 (wrapped in the PwmDuty type because it's used in other
  places here in the module as well). i don't see an easy way to make
  this configurable because i'd have to add it as a generic attribute to
  Pin and then it'd have to be defined by everyone using it
  (unnecessary for all non-PWM use-cases). but i think this should be
  acceptable as u16 probably covers most/all use-cases.
• the current code features quite some code duplication (essentially the
  method check implementations are all the same for all setters / all
  getters). i've continued this for now but it might be worth a
  refactoring in the future (i haven't touched it because i'm not sure
  if there's some strategic decision behind this?)
• there's a TransactionKind::is_get API for which i don't really see
  the reason (why not just check it directly?). i've decided to not copy
  that approach for the others as it'd IMHO just bloat the code and i'd
  instead suggest to remove TransactionKind::is_get at a later point.
• PwmPin only exists on embedded-hal 0.x, it is currently missing
  from the planned 1.0 release. see Tracking issue for PWM traits rust-embedded/embedded-hal#358 for
  the discussion on this. once it has (hopefully) been re-added there a
  corresponding mock can be provided here also for 1.x.

[dbrgn]

The PwmPin trait doesn't seem to exist anymore in e-h 1.0. Do you know what the replacement is, if any?

(Note: I'm happy to merge PRs for 0.2 as well, but that mock will become obsolete once e-h 1.0 is out.)

[rursprung]

The PwmPin trait doesn't seem to exist anymore in e-h 1.0. Do you know what the replacement is, if any?

hm, i wasn't aware of that (never looked into e-h 1.0 so far). i'll have to dig into that (probably in the next few days).
i also just saw that you're testing against rust 1.31 and that doesn't contain u16::MAX yet (i just used the latest rust stable and didn't bother checking as i didn't expect to be using anything new). should i just use a hard-coded value there or do you want to lift the MSRV instead (which is a bit stupid because i'm only using it in a test and not in the runtime code :/)

[dbrgn]

I think main is the "legacy branch", and if it's only for testing, I'd use a constant instead for now.

[rursprung]

@dbrgn: i've updated the PR a while ago so that it now should build fine with rust 1.31. i've also pushed the e-h 1.0 ticket but so far no updates there. would it be ok for you to take this into 0.x for the time being? based on the e-h discussions it seems that some form of PwmPin should eventually land in e-h 1.x again (though i do hope that the discussion leads to it already landing in 1.0).

[rursprung]

@dbrgn any chance that you could already review this for e-h 0.x while the e-h 1.x discussion is ongoing? as e-h 1.x will anyway look differently it'll require a different implementation here (if i don't forget i'll probably provide it here as well once a solution lands in e-h 1.x).
i'd like to release my motor driver (which would need this) but don't want to have a git-dependency in it (even if it's just for the test) - implicitly i'm also asking for a release of this crate after this PR gets merged 👼.
thanks!

[dbrgn]

Sorry, I missed your original comment. Thanks for the reminder! I'll take a look tonight.

[dbrgn]

I left some comments. Once these things are fixed, I can tag a new release soon!

[rursprung]

thanks for your review! i've fixed all your findings

[dbrgn]

👍🏻 thanks for the updates!

[dbrgn]

implicitly i'm also asking for a release of this crate after this PR gets merged angel

@rursprung 0.9.0 is released!