(SERVER-262) Fix `puppetserver gem env` subcommand

Without this patch the `puppetserver gem env` subcommand bombs out with the
following error:

    ERROR:  While executing gem ... (NoMethodError)
        undefined method `split' for nil:NilClass

The problem is a result of clearing the entire system environment resulting in
`ENV['PATH']` being `nil`.  This patch addresses the problem by associating
GEM_HOME and other variables into the system environment rather than clearing
it.
> This seems like it is equivalent to just using System.getEnv().  If that's the case, it seems problematic ....

I originally used `System.getEnv`, so yes, the intent is that it's equivalent behavior (plus the JRuby initialized variables)

> in the main server-side code, we consciously avoid passing any unnecessary environment variables into the JRuby interpreters to avoid loading gems and things from any unexpected directories.

Yes, and the root cause of the issue is going too far with what is treated as unnecessary.  Without this patch, `PATH` is filtered out, which is necessary.

> I wonder if we need to be concerned about the same thing here?

Regarding the balance between filtering no environment variables and filtering too many, like `PATH`...  It's tricky.  "unnecessary" is a function of perspective and the users might think some environment variables are necessary when we think they are not.

For example, the end user _may_ want to install a custom Gem, but has a compelling reason not to use the path we provide for them.  Traditionally the end user would use either GEM_HOME or GEM_PATH to accomplish this because these environment variables are designed and implemented as end-user facing public API.

By enforcing GEM_HOME and filtering out GEM_PATH we're removing this functionality, but again with good reason.  We don't want just any old code loaded into puppet-server and these sorts of variables are notoriously problematic to troubleshoot.

Since I haven't seen anyone other than me bring up how we handle GEM_HOME and GEM_PATH, I decided to preserve the explicit behavior of enforcing GEM_HOME.

As a general principle, all other (those we aren't directly concerned with) environment variables are allowed to pass.  This is so that the end user can configure libraries we use if the need to.  For example, a library may change debugging behavior if `FOO_DEBUG` is set.  If the user wants to enable debugging they'll be able to when we allow those "unnecessary" environment variables to pass.

This may be in conflict with something we've consciously avoided in the past, but I think it's worth reconsidering if we see anyone complaining about how we're handling environment variables.  It's also worth enforcing only those environment variables we know we're concerned with, e.g. GEM_HOME and GEM_PATH but not any arbitrary one.