Issue title: just call ape app
 Issue body: app is three letters so it fits the pattern. ape has the potential to be confusing and its counterparts cat and dog are gone. There's no need to be cute here. 
 Comments: 
 Comment 0: +1
 Comment 1: Merging cat/dog, was, of course, a mistake. This needs to be on the public record. Otherwise, +1.
 Comment 2: I think the tradeoff there of "you now only have to look in one place to
find out what |foo does" was worth it, but perhaps something like
cat/hood/foo/hoon -> gen/hood/foo/cat/hoon would have been better than the
current :- solution. In general, this seems to be an argument towards a
tag-based and not hierarchical file system structure :P

On Tuesday, December 1, 2015, Raymond Pasco justin76@example.org
wrote:

> Merging cat/dog, was, of course, a mistake. This needs to be on the public
> record. Otherwise, +1.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/urbit/urbit/issues/604#issuecomment-160998399.

 Comment 3: I mean, we do have hymn.hook as precedent. And as anti-precedent, mar, lib, and sur. I just think it's weird to specify it as boilerplate. I did kinda like separate dojo sigils for them.

 Comment 4: Sadly, urbit is a bit too invested into 90s filesystem layout to switch over to a tag based system :(
I was a fan of the separate dog/cats too, BTW. It makes sense from a security standpoint where compatabilies are known when you run the command instead of having to check the first cons in a source file. Definitely in favor of renaming apes, regardless.

The fact that webhooks have no only a magic file extension, but also a magic file _name_ is pretty terrible. Like, really terrible.

 Comment 5: hymn is, of course, a mark. Whether it's a good one is another story.

 Comment 6: Fixed in 2d565e75d0

{'source': 'GithubIssues', 'repo_name_with_owner': 'urbit/urbit', 'issue_id': 119609304, 'repo_stars': 3873.0}