Reloc target should probably be required to be the same as reloc entry

We currently don't require the 5-byte patchable ULEB in code and elsewhere to contain anything since all information will be overwritten by the linker based on the reloc entry. By convention we put an index there that matches the current file, but this is not required.

Tools like wasm-validate ignore the linking section however, and will report validation errors if the ULEB is always 0.

I propose that either:

1. We state that a patchable ULEB that does not correspond to its reloc is invalid, and maybe even enforce so in LLD or other consumers.
2. If we really don't care what is in here, we should make tools like wasm-validate always take the linking section into account and ignore the ULEB.
3. Don't store the value twice, i.e. remove it from the reloc entry :)

I'm guessing 1. is most practical.

Also noticed that at least for some paths, LLVM is currently hard-coding a zero for these ULEBs, I may look into fixing that: https://github.com/llvm-mirror/llvm/blob/master/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCCodeEmitter.cpp#L166

@sbc100 @binji

Read the patchable ULEB and reloc-entry convention in the linking section, then compare it with wasm-validate behavior. Inspect lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCCodeEmitter.cpp around the hard-coded zero and determine which proposed convention the tools should follow; done means the convention and affected consumer behavior are explicitly resolved.