Proposal: Add getFullProgName

[Simon Hengel]

@Johan: sorry for the duplicate

>  * we can't implement this reliably,

If I understand correctly the current System.Environment.getProgName can
make this distinction somehow.  But from a quick peek at the code, I
can't really tell how it's done.

>  * the distinction into these three groups doesn't necessarily work for all
> compilers, and

If a compiler does not support script/interactive, it could always
return Binary, right?

>  * the distinction (I assume) isn't useful in most use cases

At this point I would find it useful to define use cases.  When I was
looking for that functionality, I wanted to find files relative to a
script.  For binaries I use Cabal's support for data files, but this
only works for `cabal install`ed packages.

> I think people who want to use this heuristic are better served by the
> existing executable-path package. What do you think?

I still think that a well-tested, reliable way to do that would be
awesome.  I'm not sure how hard it is to get it right, though.

If we do not support interactive/script, then I think we should at least
use a Maybe instead of `error`.

Cheers,
Simon