Better trace file space management for clients

FoundationDB processes currently attempt to control the total amount of space they are using for trace files by rolling files periodically and deleting the oldest files when the space limit is reached. In order to avoid deleting files for other processes, this is done by deleting files with the same base name, which for server processes consists of the network address and port. Since these values are pretty stable, this works pretty well (though perhaps at some point we should consider whether the stability of these is a reasonable assumption).

For clients, on the other hand, we use the PID of the process rather than its port. This means that the size of the logs will be well controlled for as long as the process is running, but as soon as it restarts the old logs will be orphaned. A long running client can accumulate a lot of logs without any ability to clean them up itself.

There are probably a variety of ways we could address this. One is that we could change the client to log the pid with a prefix (such as 'pid1234') and have the basename for client logs not include the actual pid, resulting in the client deleting trace files from a client with any PID. This might make the behavior of multiple clients running in the same directory a little less friendly.

Another option is to allow customizing the base name to arbitrary strings that could be chosen to be more stable and descriptive. The default could be the same as today (or some variant).