Processing broken dumps correctly

Hi!

We have faced with an exception on analysing some dumps.

Crashed application had a module without name, version, etc. (it is a separate question — why it exists).

List of modules (minidump -m output) for this crash looks like that (see 2nd row):
```
...
Module|ATIRadeonX3000GLDriver|0.0.0.0|ATIRadeonX3000GLDriver|019C8FD32824C6F10FC3B2A339B4309D0|0x1c763000|0x1cb40fff|0
Module|||<Unknown>|000000000000000000000000000000000|0x1f3b2000|0x1f3b2fff|1
Module|libgfl.dylib|0.1.0.0|libgfl.dylib|8DDB177A40A23D33A5FDE85BFB0599650|0x233b5000|0x234f9fff|0
...
```

If I execute ```minidump``` by hands, it produces output:
```
...
55  OurModuleName!OurFunction [our_code.cc : 32 + 0x15]
   eip = 0x1f3b9af9   esp = 0xbffffb70   ebp = 0xbffffba8
   Found by: previous frame's frame pointer
56   + 0xf77
   eip = 0x1f3b2f78   esp = 0xbffffbb0   ebp = 0xbffffbb8
   Found by: previous frame's frame pointer
57   + 0xf54
   eip = 0x1f3b2f55   esp = 0xbffffbc0   ebp = 0xbffffbd0
   Found by: previous frame's frame pointer
58  0x1
   eip = 0x00000002   esp = 0xbffffbd8   ebp = 0x00000000
   Found by: previous frame's frame pointer
```

As you can see, it is processed correctly, but does not have a module name.

```minidump -m``` fails:
```
0|55|OurModuleName|OurFunction|our_code.cc|32|0x15
0|56|Aborted
$ 
```

I understand, that this is a problem of minidump, but it seems, that this solution is a universal guard against futher problems here.

The problem in ```minidump``` is located here:
```
breakpad/src/processor/minidump_stackwalk.cc:279       assert(!frame->module->code_file().empty());
```
, so it is not a real problem with minidump too. It seems that this patch is a good solution of a problem.