Clarify when a .patch file must be generated

The current README is unclear about when a .patch file must be generated
and how we intend to isolate our changes from upstream changes.

This patch clarifies how someone can contribute to third_party/zlib
while minimizing risk of conflicts with upstream changes.

BUG=807488

Change-Id: Iaa503b94f110cb83febbdd8d57527d606d3eb779
Reviewed-on: https://chromium-review.googlesource.com/894856Reviewed-by: Adenilson Cavalcanti <cavalcantii@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Chris Blume <cblume@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534751}

third_party/zlib/patches/README

@@ -19,8 +19,23 @@ the need to append this file with a description of what the patch does. This
 should help to solve frequent conflicts in pending new patches on
 Chromium's zlib.
 
-  The plan for the near future is to insulate better the platform specific
-changes to easy updates with new releases of zlib.
+  The plan for the near future is to better insulate the platform specific
+changes to ease update adoption with new releases of zlib. This insulation
+happens by making changes inside contrib/ rather than the root directory
+(where conflicts can happen).
+
+  If a change modifies enough things inside the root directory that the
+intention is not immediately clear, generate a .patch file to go with your
+change. If the change's modifications in the root directory are small, like:
+
+#ifdef FEATURE_FLAG
+use_special_feature();
+#elif
+use_default_behavior();
+#endif
+
+  then the intent is clear and a .patch file doesn't need to be generated (since
+it would not provide much value).
 
   Ideally local changes should have a merge request featured in either:
  - canonical zlib: https://github.com/madler/zlib/