All unit tests pass locally. There are still some lint errors in the inspector and diagnostics.dart files that still need a bit more cleanup.

Fundamentally, the core questions to address are whether the FlutterErrrorBuilder abstraction is usable and clear enough and what polish we want to apply to it before landing.

Please do not review diagnostics.dart or widget_inspector.dart.
Those changes are implementation details that have some rough edges that I will polish before sending out for further review.
The key parts to review in assertions.dart, box.dart,
and FlutterErrorBuilder, RenderErrorBuilder, and WidgetErrorBuilder.
The rest of the CL is mostly just applying the new FlutterErrorBuilder classes to all the existing errors to ensure that they generalize adequately to address all the cases. Those changes can be landed either all at once or incrementally.

This change is supposed to be non-breaking and I've jumped through hoops in a few places to make that happen. If I've missed something and added breaking logic let me know and I'll cleanup.
All tests do pass but before landing it will likely make sense to add a few more golden tests to improve the code coverage for the error generation logic.

Fyi I've layered this as two commits.
696c686
is the much smaller commits with just the critical core changes and the other commit contains using the methods from the core changes to the rest of the code base. Please start by reviewing the core change with the exception of diagnostics.dart which I'm still cleaning up.

(Jacob and I talked about this in person; I'm putting this here for the record.)

I think the problem we are solving here is real and I think it's fantastic that we are solving this. I agree with the use cases 100%.

I think we should attempt to find a solution that has a much lighter API. My fear is that engineers (that is to say, we) in general already find writing error messages to be highly aversive, and anything we do to raise the barrier to writing error messages would only make things worse. Ideally making objects in a string inspectable would require zero overhead from the perspective of framework developers. For example, one could imagine changing Object.toString or Diagnosticable.toString to encode information in the output (which normally gets stripped out but which IDEs and maybe the flutter tool can detect).

As a side note, for future refactors of this size (or indeed any API change) I recommend following our process as described here: https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
Notably, this involves filing an issue first and discussing proposals with the community (that is, anyone who is interested but in particular including myself and @goderbauer for this kind of change) before writing code. That way we can make sure to all get on the same page before we write code.