[firebase_crashlytics] Fix Printing, README, Changelog & log FlutterErrorDetails.informationCollector

[creativecreatorormaybenot]

The initial issue I was facing was that firebase_crashlytics would throw an unhandled exception on e.g. RenderFlex exceptions without a stack trace (and the stack trace formatting for exceptions with stack traces was unreadable + the reports were missing information):

Error caught by Crashlytics plugin:
[ERROR:flutter/lib/ui/ui_dart_state.cc(148)] Unhandled Exception: Invalid argument(s): Cannot create a Trace from null.
#0      new Trace.from (package:stack_trace/src/trace.dart:105:7)
#1      Trace.format (package:stack_trace/src/trace.dart:71:21)
#2      Crashlytics.onError (package:firebase_crashlytics/src/firebase_crashlytics.dart:37:19)
<asynchronous suspension>

Along the way of fixing this behavior, I noticed that the README.md file was outdated and did not even contain the breaking change from 0.1.0. Consequently, I fixed my original issue, added what was missing to the README and also adjusted some inconsistent formatting I found in the README.

I also noticed that Error reported to Crashlytics. was not even being printed and added that and also made the Result section more clear.

Notes

I found myself adding print(details) to the old onError implementation because the formatting from Trace.format is terrible for reading it in the console and it was also missing what the actual exception is, which I also added in this PR. This is the reason I averted from using Trace.format in the debug implementation.

I noticed that context was not being used in the native Android implementation, so I thought that I would add it as a string as it is a very short term describing when the exception was thrown.
Additionally, I added information and logged that using Crashlytics.log and CS_LOG. For me, this is a very crucial part for working with Flutter exceptions as it gives information about the tree, the specific widget and also some background information on why the exception occurred.

Furthermore, I noticed that the tests were printing errors when trying to access lineParts[2], which was distracting. Hence, I added a check to prevent that from happening.

If the PR itself is fine but there are minor issues like comments being abundant, then please just fix them to speed things up.

I hope that my comments also help to understand my changes.

Testing

It seems like driving examples was added for both Android and iOS now. Thus, I would assume that the tests run by CI should confirm whether the changes are implemented correctly or not as I added informationCollector and context to the test call.
The logging part I could only confirm locally by trying it out. I am not sure how I would write a test for that.

Question

After going through the code and reading the README, I am wondering if the error is also supposed to be printed locally in either of the following two scenarios because it was not printed before my change and I did not adjust that (only clarified in the README):

1. App is in release mode.

2. App is in debug mode but enableInDevMode is true.

Changelog

I fixed the changelog typo that was pointed out in #1913 by @lsaudon in here as well.

[collinjackson]

Thank you so much for the fast turnaround on implementing my suggestions.

[creativecreatorormaybenot]

Thanks for taking the time.
I added another comment explaining the current role of context and why the reason decision was made for future contributors to understand.