Merge pull request #1045 from mozilla/correct-tool-name

Fix the name used in the example

docs/user/adding-glean-to-your-project.md

@@ -161,7 +161,7 @@ buildscript {
         }
 
         dependencies {
-            classpath "org.mozilla.components:tooling-gradle-plugin:{android-components-version}"
+            classpath "org.mozilla.components:tooling-glean-gradle:{android-components-version}"
         }
     }
 }
@@ -309,7 +309,7 @@ All of Glean's target languages use a separate worker thread to do most of Glean
 {{#include ../tab_header.md}}
 
 <div data-lang="Python" class="tab">
-Since Glean performs disk and networking I/O, it tries to do as much of its work as possible on separate threads and processes. 
+Since Glean performs disk and networking I/O, it tries to do as much of its work as possible on separate threads and processes.
 Since there are complex trade-offs and corner cases to support Python parallelism, it is hard to design a one-size-fits-all approach.
 
 #### Default behavior
@@ -328,7 +328,7 @@ The default approach may not work with applications built using [`PyInstaller`](
 
 #### Using the `multiprocessing` module
 
-Additionally, the default approach does not work if your application uses the `multiprocessing` module for parallelism. 
+Additionally, the default approach does not work if your application uses the `multiprocessing` module for parallelism.
 Glean can not wait to finish its work in a `multiprocessing` subprocess, since `atexit` handlers are not supported in that context.  
 Therefore, if Glean detects that it is running in a `multiprocessing` subprocess, all of its work that would normally run on a worker thread will run on the main thread.
 In practice, this should not be a performance issue: since the work is already in a subprocess, it will not block the main process of your application.