Standard exports

The procfs package can be used to query the pseudo-filesystem commonly
mounted under /proc. It currently provides information from /proc/stat,
/proc/$pid/stat, /proc/$pid/fd and /proc/$pid/limits.

This change adds two new collectors to the prometheus package which
export metrics about a given or the current process.

* ProcessCollector exports metrics about cpu time, vss, rss, fd usage as
  well as the start time of a given process.
* GoCollector exports currently only the number of active goroutines.

Both collectors are active by default.

Background: https://docs.google.com/document/d/1Q0MXWdwp1mdXCzNRak6bW5LLVylVRXhdi7_21Sg15xQ/edit?usp=sharing
I know there was a bit of discussion about the naming. But even with the current state, I see a lot of doubling. This is `procfs.ProcProcess`, and while I like the `procfs.NewFS` below, the returntype is `procfs.ProcFS`. (The latter is common if the constructor is just `New`, but that was already discussed as confusing...)

Idea: This module is called `procfs` and deals with two fundamental objects: The proc file-system and the proc processes. We could call the former `FS` and the latter `Proc`, mirroring the two components of `procfs` and being nice and short at the same time.

So this would become `procfs.Proc`, and `procfs.ProcFS` below would become `procfs.FS`.


(On a more general node, I have the feeling we have way too many pointers and wrappers in this package. `ProcProcess` is just an int an and pointer, and its immutable. We probably don't need pointers to it, and we don't need pointer receivers. The `ProcFS` is a struct that wraps just a string. Could be just a string with methods, and no pointer receivers here, either... But I guess a simplified approach like that would change the API to something that would look less common. The current API just looks like a lot more is going on behind the scenes than it really is... But yeah, just random thoughts, I don't really want to open that can of worms.)