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.GetRunUser`.

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)
Using readers has three main benefits:

* It makes the interface for `user/` far more generalised. This is more of a subjective point, because it means that people can use the functions without the need for the library to use the filesystem (so if you have some generated data or are reading from a network connection which has sent the data you can use `user/` without needing to write a temporary file, etc). This results in the library being more testable and other minute benefits.
* It allows you to pass `nil` readers that will be used to ignore the existence of a `passwd` or `group` source and to try to carry on without them. The most obvious use of this is for files that do not exist (which was supported by the original design), but what about if you want to come up with some scheme where you can only refer to a group by its `gid` or you want to enforce that only `uid` and `gid` formats are allowed. Or maybe you want all errors when opening a file to be ignored (which was **not** supported by the original interface).
* It also creates separation of concern. The `user/` library doesn't need to know whether or not the file exists or where it is on the filesystem (if it even is on the filesystem) or if it has read access, etc. It means that the caller can do its job in getting the data and `user/` can do its job in parsing the data.