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.
With @dmitrijus and @anorkus we were discussing if removing at all the explicit file permission settings, as they should be handled by the environment or the OS of the machine where the module is run.
Unfortunately, it seems that, for some reason, the file permissions are screwed up.

While implementing the fix yesterday afternoon, I removed the mode setting in the `open` system call, i.e.

''''
int filedescriptor = ::open(filename.c_str(), O_WRONLY | O_CREAT | O_TRUNC);
''''

The PB file created has then strange file permissions.
Yesterday, I found read and write mode only for the group if setting `umask` to `0`, read mode only for the group when leaving `umask` to default `0022`. I was opening a `ssh` connection from a Linux machine.
Today, I can see read and execute permissions for the user and write mode for the group if setting `umask` to `0`, read and execute permissions for the user only when leaving `umask` to default `0022`: I am connected to the same machine from my Mac.
Then I ran `strace` on top and checked the `open` calls for PB files: you can reproduce this by changing the opening of the file descriptor as before, compiling and running

''''
$ strace -eopen cmsRun DQMServices/Components/python/test/create_filePB_cfg.py BR 2> strace_2.log
''''

By looking at the log file, you will find something like:

''''
open("./run000001/run000001_ls0001_streamDQMHistograms.pb.open", O_WRONLY|O_CREAT|O_TRUNC, 03763726256475520) = 9
open("./run000001/run000001_ls0001_streamDQMHistograms.jsn.open", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 10
open("./run000001/run000001_ls0002_streamDQMHistograms.pb.open", O_WRONLY|O_CREAT|O_TRUNC, 03763726256475520) = 10
open("./run000001/run000001_ls0002_streamDQMHistograms.jsn.open", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 11
open("./run000001/run000001_ls0003_streamDQMHistograms.pb.open", O_WRONLY|O_CREAT|O_TRUNC, 03763726256475520) = 11
open("./run000001/run000001_ls0003_streamDQMHistograms.jsn.open", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 12
open("./run000001/run000001_ls0004_streamDQMHistograms.pb.open", O_WRONLY|O_CREAT|O_TRUNC, 03763726256475520) = 12
open("./run000001/run000001_ls0004_streamDQMHistograms.jsn.open", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 13
open("./run000001/run000001_ls0005_streamDQMHistograms.pb.open", O_WRONLY|O_CREAT|O_TRUNC, 03763726256475520) = 13
open("./run000001/run000001_ls0005_streamDQMHistograms.jsn.open", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 14
open("./run000001/run000001_ls0006_streamDQMHistograms.pb.open", O_WRONLY|O_CREAT|O_TRUNC, 03763726256475520) = 14
open("./run000001/run000001_ls0006_streamDQMHistograms.jsn.open", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 15
open("./run000001/run000001_ls0007_streamDQMHistograms.pb.open", O_WRONLY|O_CREAT|O_TRUNC, 03763726256475520) = 15
open("./run000001/run000001_ls0007_streamDQMHistograms.jsn.open", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 16
open("./run000001/run000001_ls0008_streamDQMHistograms.pb.open", O_WRONLY|O_CREAT|O_TRUNC, 03763726256475520) = 16
open("./run000001/run000001_ls0008_streamDQMHistograms.jsn.open", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 17
open("./run000001/run000001_ls0009_streamDQMHistograms.pb.open", O_WRONLY|O_CREAT|O_TRUNC, 03763726256475520) = 17
open("./run000001/run000001_ls0009_streamDQMHistograms.jsn.open", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 18
open("./run000001/run000001_ls0010_streamDQMHistograms.pb.open", O_WRONLY|O_CREAT|O_TRUNC, 03763726256475520) = 18
open("./run000001/run000001_ls0010_streamDQMHistograms.jsn.open", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 19
open("./run000001/run000001_ls0000_EoR.jsn", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 19
''''

Now, the JSON file descriptors are managed by `boost` (with explicit permissions), while, for the PB files, I would expect either a call to `open` function w/o mode settings, or with mode settings where its values is taken from the process `umask`.
Instead, the mode value is a strange octal number labelling not "usual" mode masks for all the PB files: it changes from different jobs running (yesterday I found '03763323053635060', '03776530507635060', '03761643304635060', '03775240163635060', today I can see '03770260441475520', '03763505102475520', '03767222412475520', '03774311477475520') irrespective of `umask` setting.
This weird behaviour goes away if I run the code in this PR:

''''
open("./run000001/run000001_ls0001_streamDQMHistograms.pb.open", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 9
''''
Finally, I went to see the documentation for `ProtocolBuffer` output streams.
In the unit test for I/O classes, I can see that the file descriptor passed to the `FileOutputStream` constructor has file permissions explicitly set:
https://code.google.com/p/protobuf/source/browse/tags/2.4.1/src/google/protobuf/io/zero_copy_stream_unittest.cc#590
https://code.google.com/p/protobuf/source/browse/tags/2.4.1/src/google/protobuf/io/zero_copy_stream_unittest.cc#621

So, I decided to stay with permission settings in the `open` call.

I can investigate further, if you like.