✏️ Update docs to remove gender-specific references (#1824)

Co-authored-by: Sebastián Ramírez <tiangolo@gmail.com>

docs/en/docs/tutorial/background-tasks.md

@@ -2,7 +2,7 @@
 
 You can define background tasks to be run *after* returning a response.
 
-This is useful for operations that need to happen after a request, but that the client doesn't really have to be waiting for the operation to complete before receiving his response.
+This is useful for operations that need to happen after a request, but that the client doesn't really have to be waiting for the operation to complete before receiving the response.
 
 This includes, for example:
 

docs/en/docs/tutorial/handling-errors.md

@@ -47,7 +47,7 @@ In this example, when the client request an item by an ID that doesn't exist, ra
 
 ### The resulting response
 
-If the client requests `http://example.com/items/foo` (an `item_id` `"foo"`), he will receive an HTTP status code of 200, and a JSON response of:
+If the client requests `http://example.com/items/foo` (an `item_id` `"foo"`), that client will receive an HTTP status code of 200, and a JSON response of:
 
 ```JSON
 {
@@ -55,7 +55,7 @@ If the client requests `http://example.com/items/foo` (an `item_id` `"foo"`), he
 }
 ```
 
-But if the client requests `http://example.com/items/bar` (a non-existent `item_id` `"bar"`), he will receive an HTTP status code of 404 (the "not found" error), and a JSON response of:
+But if the client requests `http://example.com/items/bar` (a non-existent `item_id` `"bar"`), that client will receive an HTTP status code of 404 (the "not found" error), and a JSON response of:
 
 ```JSON
 {

docs/en/docs/tutorial/security/first-steps.md

@@ -85,7 +85,7 @@ But in this case, the same **FastAPI** application will handle the API and the a
 
 So, let's review it from that simplified point of view:
 
-* The user types his `username` and `password` in the frontend, and hits `Enter`.
+* The user types the `username` and `password` in the frontend, and hits `Enter`.
 * The frontend (running in the user's browser) sends that `username` and `password` to a specific URL in our API (declared with `tokenUrl="token"`).
 * The API checks that `username` and `password`, and responds with a "token" (we haven't implemented any of this yet).
     * A "token" is just a string with some content that we can use later to verify this user.

docs/en/docs/tutorial/security/oauth2-jwt.md

@@ -20,7 +20,7 @@ It is not encrypted, so, anyone could recover the information from the contents.
 
 But it's signed. So, when you receive a token that you emitted, you can verify that you actually emitted it.
 
-That way, you can create a token with an expiration of, let's say, 1 week. And then when the user comes back the next day with the token, you know she/he is still logged in to your system.
+That way, you can create a token with an expiration of, let's say, 1 week. And then when the user comes back the next day with the token, you know that user is still logged in to your system.
 
 After a week, the token will be expired and the user will not be authorized and will have to sign in again to get a new token. And if the user (or a third party) tried to modify the token to change the expiration, you would be able to discover it, because the signatures would not match.