Correct docs for Router::nest; other minor tweaks.

I was going to improve the discoverability of docs for how state works
with `Router::merge` and `Router::nest` based on my comment in tokio-rs#1313,
but tokio-rs#1532 removes `Router::inherit_state` so I discovered that the
change I originally suggested isn't necessary anymore.

I decided to make a few other minor documentation fixes while I was
reading, however:

* Corrected the docs for `Router::nest` to say that it nests another
  `Router` rather than a `Service`. There is a separate function
  (`Router::nest_service`) for the latter.
* Changed one of the headings in nest.md to use more idiomatic English.
* Changed awkward phrasing under the "Sharing state with handlers"
  heading of the root documentation page.
* Removed a trailing period from one of three list items for
  consistency.

axum/src/docs/routing/nest.md

@@ -1,4 +1,4 @@
-Nest a [`Service`] at some path.
+Nest a [`Router`] at some path.
 
 This allows you to break your application into smaller pieces and compose
 them together.
@@ -64,7 +64,7 @@ let app = Router::new().nest("/:version/api", users_api);
 # };
 ```
 
-# Differences to wildcard routes
+# Differences from wildcard routes
 
 Nested routes are similar to wildcard routes. The difference is that
 wildcard routes still see the whole URI whereas nested routes will have

axum/src/lib.rs

@@ -164,11 +164,12 @@
 //!
 //! # Sharing state with handlers
 //!
-//! It is common to share some state between handlers for example to share a
-//! pool of database connections or clients to other services.
+//! It is common to share some state between handlers. For example, a
+//! pool of database connections or clients to other services may need to
+//! be shared.
 //!
 //! The three most common ways of doing that are:
-//! - Using the [`State`] extractor.
+//! - Using the [`State`] extractor
 //! - Using request extensions
 //! - Using closure captures
 //!