Make value errors the responsibility of PWMOut module

[hierophect]

In most modules, value errors related to the hardware are managed by the common-hal module, so they can be made the most useful to the user. However, for the PWMOut module in particular, a set list of errors are passed back as a return enum, and then generic value errors are generated in shared-bindings. This has no difference in terms of functionality, but makes it difficult to generate useful errors for the user on different architectures. These value errors should be moved back to the PWMOut module across ports, matching the rest of the common-hal.

[dhalbert]

I spoke to @tannewt about this issue this morning. It turns out that PWMOut common-hal is used by displayio from C, so we don't really want it to throw Python exceptions. Hence the error code returns instead.

Scott would actually like to see most or all of the common-hal code be callable from C as necessary, so we should actually consider moving in the other direction.

However, it may be true that the PWMOut error codes should be generalized across ports, which I think is another thing you mentioned when we first discussed this.

[hierophect]

That makes sense. My only concern with this approach is the errors that are port or architecture specific. The benefit of port specific error codes is that you can tell the user that their system is failing because they didn't match the frequency to the existing channel they've set up, or because all channels have been reserved, etc, giving them a pathway to quickly resolve the bug. Making those errors more generic puts the user a little further from solving their problem. But perhaps that's just the price that needs to be paid for true abstraction.

[tannewt]

@hierophect All of those examples seem port agnostic. Do you know any port specific ones?