fix(proto-plus): add context to TypeErrors during message manipulation

[guptaarima]

Summary of the issue:

Context:
When using proto-plus, if a user assigns a value of an incorrect type to a message field (e.g., assigning a List[int] to a field expecting a MutableSequence[str]), the error raised originates from the underlying protocol buffer library and lacks specific details about the source of the error within the proto-plus message structure.

Actual Behavior:
The library propagates a generic TypeError from the core protobuf implementation (e.g., TypeError: bad argument type for built-in operation). This error message is cryptic because it does not identify which message class or field name received the invalid type, making it difficult for users to pinpoint the cause of the type mismatch in their code.

Expected Behavior:
proto-plus should catch these underlying TypeError exceptions during field assignments or message merging (like MergeFrom). It should then raise a new, more informative TypeError that includes context about the specific proto-plus message class and the field name involved.

For example, an improved error message could look like:
TypeError: Invalid type for field 'field_name' in message 'MessageName'. Expected but got .

This fix will significantly improve the debuggability of type-related errors when using proto-plus.

[gemini-code-assist]

Code Review

This pull request improves error handling in packages/proto-plus/proto/message.py by wrapping protocol buffer initialization and field assignment operations in try-except blocks. When a TypeError occurs during these operations, a more descriptive TypeError is raised with context about the class name, field key, and the underlying error. I have no feedback to provide as there are no review comments.