Support go_router / MaterialApp.router(…)

[IVLIVS-III]

Fixes #47

This allows combining go_router / MaterialApp.router(…) with the DialogReportMode.
It is achieved by exposing the _configureNavigatorKey instance method of Catcher2 publicly to enable updating the used navigatorKey after runApp was called.

Now users can call:

final _router = GoRouter(…);
Catcher2.getInstance().configureNavigatorKey(_router.routerDelegate.navigatorKey);

[ThexXTURBOXx]

Thanks for the PR - however, I am not quite sure whether I understand the current limitations.
Shouldn't it just be possible to do something like this?

void main() {
  final _router = GoRouter(...);
  [...other setup for catcher_2...]
  Catcher2(rootWidget: MyApp(), debugConfig: debugOptions, releaseConfig: releaseOptions,
    navigatorKey: _router.routerDelegate.navigatorKey); // this line right here
}

[IVLIVS-III]

Thanks for the PR - however, I am not quite sure whether I understand the current limitations. Shouldn't it just be possible to do something like this?

void main() {
  final _router = GoRouter(...);
  [...other setup for catcher_2...]
  Catcher2(rootWidget: MyApp(), debugConfig: debugOptions, releaseConfig: releaseOptions,
    navigatorKey: _router.routerDelegate.navigatorKey); // this line right here
}

Yes, this would be possible, however there is another limitation.
This partial solution forces you to initialize the GoRouter before calling runApp(…) / creating the Catcher2 instance.

But imagine the following scenario:

You want to display a loading screen / sign in screen first, but catch errors with loading / sign in with Catcher2.
You need data after loading / sign in to configure the routes of your GoRouter.
This forces you to create the GoRouter instance not in main but in some widget down the line.
Now you cannot provide the navigatorKey of GoRouter to Catcher2 because Catcher2 was already created before.

See this example:

void main() {
  // [...other setup for catcher_2...]
  Catcher2(rootWidget: MyLoader(), debugConfig: debugOptions, releaseConfig: releaseOptions);  // <-- cannot access `GoRouter` instance here, because it is created later
}

class MyLoader extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return FutureBuilder(
      future: …,  // <-- do some async loading call here, maybe even sign-in
      builder: (context, snapshot) {
        if (snapshot.hasData) {
          return MyApp(isAdmin: snapshot.requireData.isAdmin);  // launch the main app when future has completed
        }
        
        return Loader();  // show loader until future completes and we can launch the main app
      },
    );
  }
}

class MyApp extends StatelessWidget {
  const MyApp({required this.isAdmin});

  final bool isAdmin;
  
  @override
  Widget build(BuildContext context) {
    final goRouter = GoRouter(
      routes: [
        GoRoute("/home", …),
        if (isAdmin) GoRoute("/admin", …),  // <-- this depends on the result of the loading call, however, I want to show a loading screen and have `Catcher2` catch loading errors before
      ],
    );
    return MaterialApp.router(
      router: goRouter;
    );
  }
}

[ThexXTURBOXx]

Ah, I see. Indeed, that's an interesting use case to cover. I believe, the best way to avoid duplicate code and the like would be to just rename the _navigatorKey field to navigatorKey to make it publicly available and changeable.
Would that also work for you/could you change this in this PR? :)

[IVLIVS-III]

Yes, making _navigatorKey directly public by renaming would solve the usecase as well.
I'll change the PR accordingly.

[ThexXTURBOXx]

Thank you very much! I like that - making the field non-null is even better than it was before :)

[ThexXTURBOXx]

Thanks once again! I will publish this now as part of 2.1.3!