Investigate the possibility to move arguments from NavAction to INavDestination

[AdamKobus]

Reasoning is that destinations need args to render properly, always. NavAction's role is to simply deliver them to the new destination.

Once arguments become part of destination, it will be possible to do something like this:

// could be serialized using Gson
data class DetailScreenArgs(
    @SerializedName("itemId")
    val itemId: Int
)

object MyGraph : NavGraph("myGraph") {

    val List = navDestination("list") { ListScreen() }

    val Detail = List.nextWithArgs<DetailScreenArgs> {
        param("itemId")
    } { args -> DetailScreen(args) }
}

This way destination would declare both, the type of the used args and how it renders in one place. This could potentially make it possible to automatically build a graph with NavGraphBuilder. NavGraph methods like navDestination could remember created destiantions. This will simplify the graphs definition by a lot

Also, args should be part of the information about back stack. Currently, there is no real way to tell apart 2 instances of the same destination, even if they are launched with different set of arguments.

Potential issues:

1. How should the destination like the one below work:

   val ListDetail = List.nextWithArgs<DetailScreenArgs> {
       param("itemId")
   } { args -> DetailScreen(args) }
   
   val PicturePreview = Detail .nextWithArgs<PicturePreivewArgs> {
      path("picture")
      param("pictureId")
   } { args -> PicturePreviewScreen(args) }

   Args would need to carry both, "itemId" and "pictureId" fields. Should "pictureId" and "itemId" constants be defined in common module then?