Reader/Writer runtime exceptions could be more useful

Currently, exceptions in the generated code are all thrown as runtime errors (RuntimeError in python, std::runtime_error in c++). For example, when reading a binary stream:
https://github.com/microsoft/yardl/blob/ba89cf71c6c25764ef863b061a03921e31f24b04/tooling/internal/python/static_files/_binary.py#L80-L89

These would be more useful if they were library-defined exceptions.

For example, using mrd, if someone attempts to use a mrd.BinaryReader to open an invalid file in Python, the user will see the following:

Traceback (most recent call last):
  ...
    with mrd.BinaryMrdReader(args.input_file) as reader:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/uv/.venv/lib/python3.12/site-packages/mrd/binary.py", line 49, in __init__
    _binary.BinaryProtocolReader.__init__(self, stream, MrdReaderBase.schema)
  File "/opt/uv/.venv/lib/python3.12/site-packages/mrd/_binary.py", line 81, in __init__
    raise RuntimeError("Invalid magic bytes")
RuntimeError: Invalid magic bytes

Instead, the Python program that opens the binary reader could catch a mrd.InvalidMagicBytes exception, and print a helfpul error message, such as "Invalid file, are you sure it is in MRD format?"...

I vote we replace these runtime errors with custom exceptions that can be better handled downstream. This applies to the generated C++ and MATLAB code as well.

Start with tooling/internal/python/static_files/_binary.py at lines 80-89 and review how invalid binary input currently raises RuntimeError. Trace the corresponding generated C++ and MATLAB reader exceptions, then define library-specific exceptions that downstream programs can catch instead of generic runtime errors.