Change leptos_axum generate_route_list function to not be async

[nicoburniske]

Closes #1392

[gbj]

Could you remind me of the reason you want it to be sync?

My thinking is this:

• It's already marked async, so removing that is a breaking change that will affect all applications
• It doesn't currently need async, but being marked async means that it can use async in the future
• There are possible situations in the future when we might want it to be async. For example, people have been talking about static site generation for a long time and it might eventually be useful to build in support for that, building on generate_route_list. For example, "when I run this CLI tool I want to build static HTML versions of every page. To figure out the list of pages, I need to query the DB for blog posts." Having the flexibility to use async APIs here is useful.

So what's the use case that you need it not to be async for? Then we can weigh the pros and cons.

[rakshith-ravi]

Random joke. Ignore me

It doesn't currently need async, but being marked async means that it can use async in the future

The fact that it's async means that it already uses a Future.
Okay I'll show myself out

[gbj]

So, this PR (#1649) is a great example of why I want to keep it async, at least for now; it builds in some static-site-generation features, which rely on async, and uses generate_route_list.

[gbj]

Okay I've had a change of heart once I've looked at it in more depth, and in the context of #1649 as well (which no longer requires async route generation in this case). I think this is a good idea for consistency with the leptos_actix integration, which is not async here.

[mrvillage]

If axum is going to change, would it not be prudent to also make viz's function non-async?