collapse_exception_group breaks with exceptions that are also frozen dataclasses

Quick preface:

• this only happens with strict_exception_groups=False, and enabling strict exception groups fixes the "problem"
• I'm not even sure I would necessarily consider this a "problem" with the code per se, but it should probably be at least documented somewhere
• I realize that strict_exception_groups=False is on the deprecation march, so even if this is considered a problem, it might not be worthwhile to fix it
• feel free to immediately close as wontfix!

That being said, in the interests of "more information is always better than less information" and "something something posterity", I thought I'd throw up a quick flag: collapse_exception_group breaks if the exception it's trying to collapse also happens to be a frozen dataclass. When trio tries to set the __traceback__ attribute, dataclass' __setattr__ magic kicks in, and you get a FrozenInstanceError. Also, since this happens in the middle of nursery exception management, it kinda... blows everything up.

Again, for me, the solution was suuuuper simple -- just enable strict exception groups and update the rest of my code to match. Voila, and I get futureproofing free of charge! But it wasn't immediately clear to me that that would be a viable solution, until I poked around some inside the trio codebase. So it might be helpful to document that somewhere (I have no idea where, or I'd just have directly opened up a PR).

Start with collapse_exception_group in trio/_core/_run.py around line 147, then trace the strict_exception_groups=False behavior described in the issue. Document that frozen dataclass exceptions can fail during traceback assignment and that enabling strict exception groups avoids the problem; done means the limitation and workaround are easy to find.