Fix file creations and permissions for DQM histograms encoded with ProtocolBuffer

Several fixes to the way files containing DQM `MonitorElement` encoded with `ProtocolBuffer` are created and managed:
 * in `DQMFileSaver`, protect a function member call for `FastMonitoringService` pointer by testing whether or not is is a `nullptr`; as a consequence, `ProtocolBuffer` encoded files are saved for non-empty lumisections only in real `FilterUnit` mode;
 * in `DQMFileSaver`, when faking `FilterUnit` mode, set explicitly `umask` to `0`: this is done in order to reproduce what DAQ2 services do;
 * in `DQMFileSaver`, save files containing DQM `MonitorElement` encoded with `ProtocolBuffer` by explicitly setting permissions to `0666`: in principle, this should be handled by the environment or the OS, but `ProtocolBuffer` examples seem to require explicit file permission handling (see discussion in the code);
 * in `fastHadd`, save files merged and encoded with `ProtocolBuffer` by explicitly setting permissions to `0666`: see comment above.
Ciao @diguida 
usually programming by coincidence is a very bad practice: if there is something that does not make sense, we should try to make sense out of it, w/o touching code 'till it works as we want.

Having said that, according to open man page:

```
mode specifies the permissions to use in case a new file is created.  This argument must be supplied when O_CREAT is specified in flags; if O_CREAT is not specified, then mode is ignored.  The effective permissions are modified by the process’s umask in the usual way: The permissions of the created file are (mode & ~umask).  Note that this mode only applies to future accesses of the newly created file; the open() call that creates a read-only file may  well return a read/write file descriptor.
```

I would therefore:
1. decide what are the permission that we want to use to create PB files: and these permission should be driven by what we have to do on these files.
2. Code the open call in such a way that those permission are granted.

To this extent, I would suggest to verify, both via shell and via C(++), what is the umask of the owner of the process and the real umask while running within the process itself.

Everything should behave as documented in man pages. If not we have to understand why.