Allow injection of proxy configuration, instead of environment variables.

PR #1243 introduced proxy support via environment variables, specifically `process.env`. See https://github.com/grpc/grpc-node/blob/%40grpc/grpc-js%400.7.0/packages/grpc-js/src/http_proxy.ts#L45-L56

Sole reliance on environment variables (global scope), while a common occurrence, violates the Dependency Inversion principle by tightly coupling the location of the proxy configuration. In practice, this means that the inclusion of a proxy configuration cannot readily support the following use cases:

- Reading from a filesystem; e.g. kubernetes secrets mount, or kubernetes init container pattern (using emptydir for config loading)
- Application layer integration with a configuration management system and/or secrets vault; e.g. SDK use of GCP Secret Manager or HashiCorp Vault/Consul.

These use cases also apply to the scenario where an _authenticated_ proxy is used and the credentials (secrets) would/should not be present in environment variables.

### Solution
Allow dependency injection of a proxy configuration, via one or both of:
1. `proxy` as part of `grpc.Client#options`, I don't think `noProxy` would be required since the `Client` is bound to a single URI
2. `proxy` and `noProxy`, possibly, as part of `grcp.loadPackageDefinition` or similar where it has a more global effect across the grpc library.

### Possible workaround
A workaround is to read the proxy configuration via one of the two previously mentioned use cases and set them directly on `process.env` _before_ the `@grpc/grpc-js` module is loaded (`require`d). It is important that it happens prior to requiring given that the proxy options are determined at module load time and _not_ at the time of proto instantiation nor client creation.