Remove _with_issue() proto conversion and make errors more explicit #239

What's needed?

The family of functions xxx_from_proto_with_issues() are very precarious. Errors are just arbitrary strings, making it very hard to act on, and very fragile (a change in the message could mean breakage).

We need a better way to validate and report errors.

Proposed solution

We should move forward with the approach to report issues via special representation (like ProblematicElectricalComponent) or make errors fails more loudly for safe access, like the enum accessors that raise on UNSPECIFIED or unrecognized values.

At the end the goal is to remove _with_issues() conversion function flavors and ideally return a representation of an invalid object on failures, so users can still inspect the invalid data in case they want to apply some custom error recovery. Sometimes it might be fine to simply raise an error in the conversion function, but that should be a last resort measure.

Additional context

As a second stage, alternative ways to deal with errors could be provided, but probably as separate functions. For example we could add a validate() function or method, that checks all the data in an instance is valid. It could raise on the first error or collect errors, or log them, we can make error reporting pluggable.