[android] Change the recommended log tag format to "cr_foo"

docs/android_logging.md

 # Logging #
 
 [TOC]
 
 
 ## Overview
 
 Logging used to be done using Android's [android.util.Log]
 (http://developer.android.com/reference/android/util/Log.html).
 
 A wrapper on that is now available: org.chromium.base.Log. It is designed to
 write logs as belonging to logical groups going beyond single classes, and to
 make it easy to switch logging on or off for individual groups.
 
 Usage:
 
 ```java
-private static final String TAG = "cr.YourModuleTag";
+private static final String TAG = "YourModuleTag";
 ...
 Log.i(TAG, "Logged INFO message.");
 Log.d(TAG, "Some DEBUG info: %s", data);
 ```
 
 Output:
 
 ```
-I/cr.YourModuleTag: ( 999): Logged INFO message
-D/cr.YourModuleTag: ( 999): [MyClass.java:42] Some DEBUG info: data.toString
+I/cr_YourModuleTag: ( 999): Logged INFO message
+D/cr_YourModuleTag: ( 999): [MyClass.java:42] Some DEBUG info: data.toString
 ```
 
 Here, **TAG** will be a feature or package name, "MediaRemote" or "NFC" for
-example. In most cases, the class name is not needed.
+example. In most cases, the class name is not needed. It will be prepended by
+the "cr_" prefix to make obvious which logs are coming from Chrome.
 
 ### Verbose and Debug logs have special handling ###
 
 *   `Log.v` and `Log.d` Calls made using `org.chromium.base.Log` are stripped
     out of production binaries using Proguard. There is no way to get those logs
     in release builds.
 
 *   The file name and line number will be prepended to the log message.
     For higher priority logs, those are not added for performance concerns.
 
 ### An exception trace is printed when the exception is the last parameter ###
 
 As with `java.util.Log`, putting a throwable as last parameter will dump the
 corresponding stack trace:
 
 ```java
 Log.i(TAG, "An error happened: %s", e)
 ```
 
 ```
-I/cr.YourModuleTag: ( 999): An error happened: This is the exception's message
-I/cr.YourModuleTag: ( 999): java.lang.Exception: This is the exception's message
-I/cr.YourModuleTag: ( 999):     at foo.bar.MyClass.test(MyClass.java:42)
-I/cr.YourModuleTag: ( 999):     ...
+I/cr_YourModuleTag: ( 999): An error happened: This is the exception's message
+I/cr_YourModuleTag: ( 999): java.lang.Exception: This is the exception's message
+I/cr_YourModuleTag: ( 999):     at foo.bar.MyClass.test(MyClass.java:42)
+I/cr_YourModuleTag: ( 999):     ...
 ```
 
 Having the exception as last parameter doesn't prevent it from being used for
 string formatting.
 
 ## Logging Best Practices
 
 ### Rule #1: Never log PII (Personal Identification Information):
 
 This is a huge concern, because other applications can access the log and
@@ skipping 113 matching lines @@
 ```java
 Log.d(TAG, "fields [%s,%s,%s]", value1, value2, value3);
 ```
 
 ## Filtering logs
 
 Logcat allows filtering by specifying tags and the associated level:
 
 ```shell
 adb logcat [TAG_EXPR:LEVEL]...
-adb logcat cr.YourModuleTag:D *:S
+adb logcat cr_YourModuleTag:D *:S
 ```
 
 This shows only logs having a level higher or equal to DEBUG for
-`cr.YourModuleTag`, and SILENT (nothing is logged at this level or higher, so it
+`cr_YourModuleTag`, and SILENT (nothing is logged at this level or higher, so it
 silences the tags) for everything else. You can persist a filter by setting an
 environment variable:
 
 ```shell
-export ANDROID_LOG_TAGS="cr.YourModuleTag:D *:S"
+export ANDROID_LOG_TAGS="cr_YourModuleTag:D *:S"
 ```
 
 For more, see the [related page on developer.android.com]
 (http://developer.android.com/tools/debugging/debugging-log.html#filteringOutput)