Cross-origin errors aren't accessible by React in DEV mode because we
catch errors using a global error handler, in order to preserve the
"Pause on exceptions" behavior of the DevTools. When this happens, we
should use a custom error object that explains what happened.

For uncaught errors, the actual error message is logged to the console
by the browser, so React should skip logging the message again.

In DEV, the browser always logs errors thrown inside React components,
even if the originating update is wrapped in a try-catch, because of the
dispatchEvent trick used by invokeGuardedCallback. So the error logger
should not log the message again.

In DEV, we don't want to print the stack trace because the browser already always prints it.
We'll just print the component stack now.

In PROD, we used to omit the JS error message. However we *do* want to show it because
if the application swallows the error, the browser will *not* print it. In DEV it works
only because of the fake event trick. So in PROD we will always print the underlying error
by logging the error object directly. This will show both the message and the JS stack.

There's a few goals in the rewording:

* Make it tighter using line breaks between sentences.
* Make it slightly less patronizing ("You should fix it" => "You can find its details in an earlier log")
* ^^ This also helps highlight that the real error message and stack is above
* Group subsections: intro (there's an error), component stack, and final addendum about error boundaries
* ^^ Otherwise people might think error boundaries are part of the reason they have an error
* Make it clear "located at" is not the stacktrace. Otherwise it feels confusing. This makes it clearer you should still look for stack trace (with other details) above and introduces the concept of component stack.