HeapAnalysis in release builds: next steps

[pyricau]

Some future work to consider because we can make it stable.

• Rethink the artifact name. leakcanary-android-releases sounds like it builds on top of leakcanary-android, when the only dependency is Shark.
• Not sure if "Job" is the right word. Not call. Maybe Task? It's something that can be executed exactly once, with a blocking call to execute(), but can also be canceled from a separate thread.
• Consider splitting the work into composable jobs, ie dump heap + strip hprof + analyze hprof, with some reporting (need to think of the difference between interceptors and events). Once that's done we might get to a core pipeline that could also be used to build LeakCanary itself on top. That would allow us to provide a much more customizable API out of the box (e.g. replace the toast, etc). The core pipeline pieces could also be JDK only (obviously the heap dumping impl is android specific).

[pyricau]

HeapAnalysisJob.execute() should maybe not be visible from interceptors / Chain.