Change first-person to second-person in README

This changes the few instances of "I" to "you" to match the rest of the
README.

README.md

@@ -32,8 +32,8 @@ development and easily swap in other strategies later.
 ## Getting Started
 Each OmniAuth strategy is a Rack Middleware. That means that you can use
 it the same way that you use any other Rack middleware. For example, to
-use the built-in Developer strategy in a Sinatra application I might do
-this:
+use the built-in Developer strategy in a Sinatra application you might
+do this:
 
 ```ruby
 require 'sinatra'
@@ -45,7 +45,7 @@ class MyApplication < Sinatra::Base
 end
 ```
 
-Because OmniAuth is built for *multi-provider* authentication, I may
+Because OmniAuth is built for *multi-provider* authentication, you may
 want to leave room to run multiple strategies. For this, the built-in
 `OmniAuth::Builder` class gives you an easy way to specify multiple
 strategies. Note that there is **no difference** between the following
@@ -82,14 +82,14 @@ environment of a request to `/auth/:provider/callback`. This hash
 contains as much information about the user as OmniAuth was able to
 glean from the utilized strategy. You should set up an endpoint in your
 application that matches to the callback URL and then performs whatever
-steps are necessary for your application. For example, in a Rails app I
-would add a line in my `routes.rb` file like this:
+steps are necessary for your application. For example, in a Rails app
+you would add a line in your `routes.rb` file like this:
 
 ```ruby
 get '/auth/:provider/callback', to: 'sessions#create'
 ```
 
-And I might then have a `SessionsController` with code that looks
+And you might then have a `SessionsController` with code that looks
 something like this:
 
 ```ruby
@@ -108,7 +108,7 @@ class SessionsController < ApplicationController
 end
 ```
 
-The `omniauth.auth` key in the environment hash gives me my
+The `omniauth.auth` key in the environment hash provides an
 Authentication Hash which will contain information about the just
 authenticated user including a unique id, the strategy they just used
 for authentication, and personal details such as name and email address
@@ -163,7 +163,7 @@ a `session_store.rb` initializer, add `use ActionDispatch::Session::CookieStore`
 and have sessions functioning as normal.
 
 To be clear: sessions may work, but your session options will be ignored
-(i.e the session key will default to `_session_id`).  Instead of the
+(i.e. the session key will default to `_session_id`).  Instead of the
 initializer, you'll have to set the relevant options somewhere
 before your middleware is built (like `application.rb`) and pass them to your
 preferred middleware, like this: