slog-handler-guide: prose tweak, re-make README

Change-Id: I470379d7ff14e8d3233556d70e499b19736f27a6
Reviewed-on: https://go-review.googlesource.com/c/example/+/515556
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>

slog-handler-guide/README.md

diff --git a/slog-handler-guide/README.md b/slog-handler-guide/README.md
index 946f653..89b6109 100644
--- a/slog-handler-guide/README.md
+++ b/slog-handler-guide/README.md
@@ -910,7 +910,7 @@
 
 Allocation is often a major cause of a slow system.
 The `slog` package already works hard at minimizing allocations.
-If your handler does it own allocation, and profiling shows it to be
+If your handler does its own allocation, and profiling shows it to be
 a problem, then see if you can minimize it.
 
 One simple change you can make is to replace calls to `fmt.Sprintf` or `fmt.Appendf`
@@ -1010,4 +1010,4 @@
 wasted.
 The extra memory might never be used again by the handler, and since it was in
 the handler's pool, it might never be garbage-collected for reuse elsewhere.
-We can avoid that situation by keeping large buffers out of the pool.
+We can avoid that situation by excluding large buffers from the pool.

slog-handler-guide/guide.md

diff --git a/slog-handler-guide/guide.md b/slog-handler-guide/guide.md
index 969415f..7aa4d7e 100644
--- a/slog-handler-guide/guide.md
+++ b/slog-handler-guide/guide.md
@@ -708,4 +708,4 @@
 wasted.
 The extra memory might never be used again by the handler, and since it was in
 the handler's pool, it might never be garbage-collected for reuse elsewhere.
-We can avoid that situation by keeping large buffers out of the pool.
+We can avoid that situation by excluding large buffers from the pool.