fix grpc threadpool size

[hrfuller]

Problem

The number of grpc completion queues on the host is tied to the requested remote concurrency. The remote concurrency numbers are likely to be much larger than the available cores on the host machine creating thread management overhead on the host.

Solution

Use the built in GRPC EnvBuilder class which picks a sensible number of completion queue / threads based on the host proc count.

Result

The user wont have to worry about strange side effects on the host when increasing remote concurrency.

[illicitonion]

Seems reasonable - I haven't dug into the underlying C++ here, and it's not super well documented outside the code, but if it starts causing problems we can look at it then... :)

[hrfuller]

The method grpc uses to get cpu count boils down to reading a /sys file at runtime.

[hrfuller]

Looks like this PR is slightly increasing the memory overhead in one of the pantsd integration tests. Probably lay off merging for now, until I figure out why.

Edit. Though if you have any idea why a few less grpc threads would be causing a memory increase in the daemon across mulitple runs let me know!