Update front-facing help and error messages for Android targets/tasks

Small improvements to an exception message and a CLI flag.
The missing manifest error in android_target didn't give
any hints as to where the bad BUILD file entry was pointing.

And the sdk-path CLI flag for android_task wasn't clear about what it did.
It could easily have been interpreted as forcing a platform
version (i.e. SDK platform 17) as opposed to what it
actually is meant to do, which is point to an entire
Android SDK installation somewhere on the filesystem.

The use case is to force a custom SDK over the AOSP one on
the machines path. Lots of OEM customize the framework and
might have multiple SDKs on the fs.

Testing Done:
CI passes.

Travis passes [0].

[0] https://travis-ci.org/pantsbuild/pants/builds/31784570

Reviewed at https://rbcommons.com/s/twitter/r/837/
Rename pants.goal.goal.Goal to pants.goal.task_registrar.TaskRegistrar.

Rename pants.command.goal.Goal to pants.command.goal_runner.GoalRunner.

There is now no class called Goal, no file called goal.py and no target called :goal anywhere.
Add assert_list to ensure an argument is a list

Testing Done:
Ran unit tests locally

Reviewed at https://rbcommons.com/s/twitter/r/811/
Updates error message when referencing the wrong path to a BUILD file.

Before, it would just spit out the incorrect BUILD file path.:

  Exception message: BUILD file does not exist at: /Users/zundel/Src/Pants/src/java/com/pants/examples/annotation/exampleTYPO

Now it will read as follows:

  Exception message: BUILD file does not exist at: /Users/zundel/Src/Pants/src/java/com/pants/examples/annotation/exampleTYPO
    referenced from src/java/com/pants/examples/annotation/processor:processor
    referenced from src/java/com/pants/examples/annotation/main:main

Testing Done:
Updated unit tests, ci passed at https://travis-ci.org/pantsbuild/pants/jobs/31812266

Bugs closed: 442

Reviewed at https://rbcommons.com/s/twitter/r/841/
Got ivy to map in javadoc and source jars for pants goal idea.

This involved a fair amount of finagling with conf variables spread across ivy_* and ide files,
and some changes to the ivy mustache. The mechanism by which confs are currently passed around
does not seem very robust. The whole system would probably benefit from some refactoring to
abstract away ivy's inner workings and streamline generic mapping settings; it would be nice to
have an abstract interface for mapping jar files. This could  also make it easier to deal with
failing downloads, parallelization, or using a different jar mapping tool, but all that can
wait for an entirely different review.

Also cleaned up some style issues that got missed in the last patch for the idea goal.

Don't do extra work if no one wants sources.