Remove panics in enum mappers

[c-warren]

What changed?

Removes panic() from enum mappers in types/mapper/...

Why?

It is idiomatic in go to return an error value when something expected goes wrong.
In general panics should be reserved for situations which are unrecoverable for the entire process, and killing the process and restarting it is the expected behavior.
Even in these scenarios, libraries or portions of the call stack that are not at the request level should favor returning errors to the caller and allowing the caller to decide whether or not the runtime should panic - deferring the decision to the last moment (e.g a panic/recover handler at the request level.

How did you test it?

There are three scenarios for each of our mapping functions:

• An expected invalid value is passed (nil or PROTO_ENUM_INVALID)
• A valid value is passed
• An invalid value/out of bounds value is passed

With the existing mapping round trip tests scenarios 1 and 2 were tested, but scenario 3 was not.
This PR adds tests for the ToXXX and FromXXX mappers as well to ensure that there aren't strange behaviors that are covered up by the full round trip.

Potential risks

This could be a breaking change to our API for some users. If, for example, a consumer is passing an invalid enum value to a specific RPC and then relying on an Internal_Server_Error with a specific panic message to do some business logic, they will unfortunately not be happy.

Release notes

N/A

Documentation Changes

N/A

[Shaddoll]

Do you mind creating a private in monorepo and deploy it to a dev environment and run?

This is a risky change and just want to make sure it won't block our release. Our release has been paused for 2 weeks because of the library upgrade.