This change changes and documents the (previously undocumented) behavior of Used
to "RAM used by programs".

We also remove the undocumented and unused Shared field of that struct.

So with this change in place, the VirtualMemoryStruct contains:
* three human-consumable fields for Total, Used and Available memory
* one human-consumable UsedPercentage field
* a number of kernel specific fields

Use OS calls rather than exec() to get memory stats on Darwin

Before this change we used to exec() various binaries to find out memory
information.

While this worked, it was awfully slow.

And if somebody would want to compute how many percent of available memory all
PIDs on the system uses, that would take almost ten seconds on my laptop with
the previous implementation.

This implementation fares a lot better, and is smaller.

process: Implement MemoryPercent() for Darwin

It calls mem.VirtualMemory() and process.MemoryInfo(), so on the platforms where
those work MemoryPercent() will as well.

Tested on Darwin.

Add build check

add circle.yml.

Return correct user name from process.Username()

process.Process.uids is an array of undocumented values.

That one of them is the user that the process is running as is obvious, but what
the other two are supposed to be is AFAICT undocumented.

On Darwin, the second and third UID (out of three) seem to always be 0.

This change removes the two always-zero UIDs from the process.Process struct on
Darwin, and leaves just the one that actually identifies the user the process
is running as.

Before this change, process.Username() returned "root" for all processes on
Darwin.

Make a public function for computing total CPU time

This function used to be a private part of process.go.

Since I needed that functionality however I think it's better to make it public
than for me to copy it into my own code.

As a side effect of this change, I also fixed a bug in the function where Stolen
was not part of the sum. Having the function close to the CPUTimesStat
declaration will make problems like this less likely to re-occur in the future.

fix meminfo output on consecutive calls

There are two possible error scenarios for CallPgrep.  

try to fix diskio stats on FreeBSD-10.x

FreeBSD apparently changed the magic sysctl mib values for devstats.

    --- FAIL: TestDisk_io_counters (0.00s)
    disk_test.go:39: error no such file or directory
    disk_test.go:42: ret is empty, map[]

This code uses an undocumented, but exported, go stdlib method to fetch
the sysctl by string instead of mib.

system (no pgrep command) and one is a normal error state of pgrep
meaning no processes found for the criteria given (in this case the parent
pid does not exist or the process simply has no children).  The later case
is quite usefull to know about so I added a static error for this case.