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 @rovere 
I agree with you: programming by coincidence *must* be avoided: I can guarantee that it is not the case for this PR :-)
Now, concerning the changes I am implementing here (point 1 of your comment): DAQ2 developers argued file permissions to be 0666 (as the json files) in order to ease maintenance and debugging.
Moreover, when faking FU mode, we want to reproduce as much as possible the behaviour of the DAQ2 environment.
Finally, I also spotted a regression, that must be fixed.
Then, what I did was:
1. read the `open` documentation and the meaning of all the flags therein defined. After reading many times and discussing with others, I finally spotted the problem:

````
The mode argument must be supplied when O_CREAT is specified in flags; if O_CREAT is not specified, then mode is ignored.
````

Basically, creating a file descriptor without providing file permissions in `open` is a bug: the mode is set erratically (well, the documentation is not very clear, but the logic is: when you create a new file, you should specify the permissions). Thanks for reviewing this!
2. Setting the flags as DAQ2 wants.
3. Protecting the function call in order to fix the regression.
These features are accomplished by this PR, and the possible bug in the `open` call is not there because I set the mode.

Now, I am trying to better understand the data flow in DAQ2. What we know for sure is:
1. the FU process `umask` is set to `0`, so the permissions we set will not be changed by the process environment: https://github.com/cms-sw/cmssw/blob/CMSSW_7_2_X/EventFilter/Utilities/src/EvFDaqDirector.cc#L109
2. the user producing the file must have full control on it, so read and write permissions on user are granted;
3. The merging of histograms in PB files is done on a new file on FU, BU, and SM2, while event data files are cut: as a consequence, I would remove write permissions by others, keeping read permissions for testing/debugging purposes;
4. After being merged on FU, BU, and SM2, original input files are removed: now, we have to understand who does this. If UNIX groups are used cleverly, I would argue that all users in DAQ2 running FU processes and data file handling services (merging, moving, deleting) are at least in the same group, and that in each step the files are handled by the same user (e.g. in the FU, the user running the `cmsRun` process is the same running the merging, the moving to the BU, and the deletion of old files, but it can be different from the user running the merging, moving and deletion in the BU). If so, the PB files should have also the write permission granted to the group.
The net result is that the file permissions on the PB files should be set to `0664`.