If we have an (invalid) relocation which relocates bytes which partially
lie outside the range of the relocated section, the getRelocatedValue
would return confusing results. It would first read zero (because that's
what the underlying DataExtractor api does for out-of-bounds reads, and
then relocate that zero anyway.
A more appropriate behavior is to return zero straight away. This is
what this patch does.