Show revamp

Complete rewrite of 'meteor show', with tests. See commit messages for more details.

This is part of the work on the Meteor tool to get longform package descriptions from README.md files into 'meteor show'. It is safe-contained enough, that it makes sense to submit it for review.

(I won't merge to devel until all the README work is complete -- note that this is being pulled to a staging branch).
How about pulling in 'record' into the options as well? Then the function API is consistent, in that everything is in options. (Instead of one non-options mandatory argument, one options mandatory argument, and a bunch of optional arguments in options.)

Here is my take on why I don't really feel that projectContext is a 'most important argument': it is a way to provide context, yes, but it could just as easily NOT be mandatory. For example, there is a potential world where we provide a localCatalog and a troposphere separately. There is a potential world where we have multiple official catalogs or package servers, and have to pass that in as an option as well.

So, while the information that we provide is important, it is (1) one of the many potential bits of important information and (2) the method of providing it (projectContext) is definitely implementation-dependent. (I thought about splitting it up, but I think it is actually cleaner to provide it through projectContext right now. But maybe I will now convince myself that it is not?)

The same arguments could be used for the record as well, I guess -- we provide it because (1) we need to provide a name and (2) if we didn't provide it, we would likely need to fetch it again anyway, so it is not really efficient to just throw it out. But, once again, that's just a detail. For example, if we knew that something is a package, we could just pass in the name, and ask PackageQuery to fetch the record for us. In a sense, that would be more elegant -- in our reality, it would be stupidly inefficient (since we have the record anyway). But maybe it is nice to leave the door open to that world.

My third consideration here is kind of selfish -- I think that PackageQuery and ReleaseQuery are similar, and I think that it makes it somewhat cleaner to try and keep their API also, somewhat similar. If they both take in 'options' and you need to think a little about what those options are, that makes sense to me. If one of them takes in 'record' and 'projectContext' and the other takes in, for example, 'record' and 'officialCatalog', that would introduce a weird asymmetry. I would be (mildly) concerned about someone messing it up, or otherwise wasting time being confused. Granted, I don't think that's a particularly strong reason, just a selfish one (selfish, because I want things to be pretty and symmetrical).

(*) As a point of friendly discussion that is not related to this necessarily, but is a topic that I am curious to discuss (since you have strong opinions on it, and they are maybe different from the opinions that I have encountered previously -- feel free to totally ignore this section!):

I understand what you mean with "hiding a lot of arguments in the "options" makes it hard to see what is up with the function based on the signature"! That's definitely true, and it is especially frustrating when there are no comments explaining what the options are. I don't think that you should ever have to look at the code to figure out what is going on (at the API level anyway).

On the other hand, it is a lot easier on the caller, sometimes. Having to remember argument order can be super frustrating! Also, example usage is easier to understand: encountered in the wild, foobar({ name: x, version: y, dependency: z }) is a lot less confusing than foobar(x, y, z)! 

So, I have been erring on the 'put things in options + comments' side, but I am curious about your opinion as well.