Refactor and expose private functions within `libcontainer/user`.

This patchset refactors much of the code in `user/` (such as using structs to return user data and general readability improvements), exposes several previously private functions (`parsePasswdFile`, `parseGroupFile`) to allow for callers to pass `io.Reader`s as a data source (massively improving the usability of the package) and adds several exhaustive unit tests for RunUser parsing.

Also, the gargantuan function signature `user.GetUserGroupSupplementaryHome` was changed to the more readable and understandable `user.GetExecUser`.

This patch was created to assist the implementation of docker/docker#7537, in order to ensure the RunUser configuration parsing can be handled consistently both internally to libcontainer, as well as external to libcontainer.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> (github: cyphar)
@crosbymichael @tianon: While I understand wanting `nil` returns (and that is fair enough), the reason I did it this way was because `ExecUser` struct values are just a representation of an abstract concept, and thus don't make sense to be pointer-ised (is that even a word). Basically, the way I've always learnt to use pointers is:

> Only use pointers if the data it points to may change underneath you, and such changes make the old values invalid.

In other words, things like terminal or server structs might make sense to pointer-ise (the terminal or server may change states, and thus the old value is invalid) but when you're dealing with abstract representations of parsed user specifications (IMO) it doesn't really make sense to make them pointers (since the actual point of a pointer -- the ability to change the value it points to, and all users of that pointers now use the updated value -- is not used).

EDIT: Also, the old function didn't use nil returns -- it returned all of the struct fields as separate return values -- so we haven't really lost anything.