Harden system calls plus.

[drgrice1]

This does the things that I asked @drdrew42 to address in #1392. Since @drdrew42 seems to not have time to deal with that (due to the lack of response to my comments) I am opening this pull request.
This also addresses the fourth security vulnerability that @drdrew42 mentioned in the Slack securityresponseteam channel. Basically, it only allows symlinks to be created to a file that is in the $WeBWorK::PG::IO::pg_envir->{directories}{permitted_read_dir}.

That does allow following symlinks, so for webwork2 that includes anything in or linked to in the course directory. That means OPL static image files will work, or files in the webwork2/assets/pg/Student_Orientation directory (for example). One case that was allowed before that this doesn't allow is a file in the webwork2/htdocs/images directory. I don't really see a need to allow those files though.

For the standalone renderer that is the root directory of the standalone renderer app (by default).

This could be considered for a hotfix as @drdrew42 mentioned in #1392.

[somiaj]

A hotfix is probably a good idea. I would say add a PR for that so we can approve/merge both at once.

Do you have any test problems to illustrate what is being hardened?

[drgrice1]

@drdrew42 posted four problems that cover the cases in the securityresponseteam channel in slack. Note that they wrote the problems to work for the standalone renderer in a docker container. So the directories they use need to be modified for webwork2. They also do something in the third problem that is not possible for webwork2. That is they read the file written to the htdocs temporary directory. For webwork2 that is not possible because the htdocs temporary directory is not contained (or linked to) in the course directory. I will try to post problems that work for webwork2 later, but I don't have them with me now.

[drgrice1]

I posted the problems in the securityresponseteam channel on slack for testing this pull request.