add current values to rlimit retrieval

[phemmer]

This implements the proposal in #344

During development of this, I uncovered a few issues with the current state of things.

1. RlimitStat uses int32 for the limit values. This is insufficient as limits can overflow an int32.
2. Rlimit() uses math.MaxInt32 to denote unlimited. It's possible for this to be the actual value of a limit. RLIMIT_INFINITY is typically -1 for this reason. Edit: This is really related to the first issue. The kernel uses -1, but once we're using uint64, the max value of the type is accurate as the -1 underflows to the max uint64 value.

There is one deficiency in this implementation. There is no way to differentiate between "no current value" and "current value is 0". We could use int64(-1) to indicate "no current value). This might make sense if we fix the RlimitStat issue to also use int64(-1) for unlimited. Open to suggestions.

Also from a consumer point of view, working with the rlimits is very cumbersome. If the consumer of gopsutil wants to get a specific rlimit, they have to iterate through every one to find the one they want. A map[int]RlimitStat (with the int key being RLIMIT_* constants) would be much easier to work with.
From a consumer standpoint, it would also be convenient if there were a way to get the string name for a RLIMIT_* constant. Currently the consumer needs to maintain a map of the int values to their string names.

Closes #344

[phemmer]

Ping? Any feedback?

[shirou]

Sorry, I have not noticed.

But this PR seems to change Rlimit API. API change is not acceptable until v3 (and v3 release is not scheduled). How about implement as other function?

[phemmer]

PR updated to introduce functionality as a new function. Original Rlimit() function is just a passthrough to new function with static arg.

[phemmer]

ping?

[shirou]

Sorry late, and thank you so much for your cool contribution!