Support EOF data in debug data entries.

[DaZombieKiller]

This pull request adds support for debug data entries located in EOF data, which are valid according to the PE spec:

Each debug directory entry identifies the location and size of a block of debug information. The specified RVA can be zero if the debug information is not covered by a section header (that is, it resides in the image file and is not mapped into the run-time address space). If it is mapped, the RVA is its address.

The file offset is also now preferred over the RVA when the file is not mapped.

[Washi1337]

Tests seem to fail because some debug data entries can have no contents (i.e., size == 0, and thus also pointer/address to raw data == 0, see HelloWorld.exe test binary).

We can't really return null for these entries or we lose the debug entry type. This is a downside of the current design on how debug data is modeled, as the entry type is currently only exposed by IDebugDataSegment to make it easier for end-users to add or swap out new debug data entries without having to specify the debug data type twice (i.e., the value of the DebugDataEntry::Contents implies the type of debug data).

Two options I see now:

1. We reintroduce the Type property in DebugDataEntry, accepting that this is less ergonomic for end-users that want to add or modify debug data entries.
2. We introduce an EmptyDebugDataSegment of sorts (or maybe reuse CustomDebugDataSegment), which is special cased for in the writer, allowing for empty debug entries to exist.