Yarp: Network.h contains methods that should be somewhere else

[Nicogene]

Network for yarp have ever been a superclass that does a lot of stuff, some of them not directly related to the network or communication.

Giving a look to Network.h I found that these methods:

    /**
     *
     * Read a variable from the environment.
     *
     * @param key the variable to read
     * @param found an optional variable to set to true iff variable is found
     * @return the value of the environment variable, or "" if not found
     *
     */
    static std::string getEnvironment(const char *key,
                                      bool *found = nullptr);

    /**
     *
     * Set or change an environment variable.
     *
     * @param key the variable to set or change
     * @param val the target value
     *
     */
    static void setEnvironment(const std::string& key, const std::string& val);

    /**
     *
     * Remove an environment variable.
     *
     * @param key the variable to remove
     *
     */
    static void unsetEnvironment(const std::string& key);


    /**
     *
     * Get an OS-appropriate directory separator (e.g. "/" on linux)
     *
     */
    static std::string getDirectorySeparator();

    /**
     *
     * Get an OS-appropriate path separator (e.g. ":" on linux)
     *
     */
    static std::string getPathSeparator();

should stay somewhere else, in a sort of utility header, what do you think about it?

This should make Network a lighter class, that does only what it have to do, making it easier to handle and maintain.

This is not a blocking issue, but I think it is something to not ignore because this(like other cases) causes "cross-dependencies" because some things are not in the right place.
For example see this comment

[Nicogene]

@drdanz shall we move in yarp::conf::environnment the setEnvironment, getEnvironment and unsetEnvironment?

[drdanz]

Yes, but before doing that I'd like to find out if there is some proposal to the standard, or something similar. There are already std::setenv and std::getenv in cstdlib, but I'd like to investigate if there is any plan for c++-like methods

[drdanz]

Fixed by #1855 and #2334