New alias handling not compatible with LLVM 3.4

Edit: we're going to leave GHC 7.10 broken with LLVM 3.4 as described below, but then we should at least update GHC's information about which versions of LLVM it can use.

---

As reported by Joachim here: https://www.haskell.org/pipermail/ghc-devs/2014-November/007480.html, and it happens for me too. It seems to affect every program compiled with -fllvm; T5681 just happens to be the only such program in the normal test suite.

Faced with the definitions

@Main_zdwwork_info_itable$def = internal constant %Main_zdwwork_entry_struct<{
    i64 add (i64 sub (i64 ptrtoint (i8* @S2ZH_srt to i64),i64 ptrtoint (
      void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)*
      @Main_zdwwork_info$def to i64)),i64 8),
    i64 4294967299, i64 0, i64 4294967311}>,
  section "X98A__STRIP,__me3", align 8
@Main_zdwwork_info_itable = alias i8* bitcast
  (%Main_zdwwork_entry_struct* @Main_zdwwork_info_itable$def to i8*)

LLVM 3.4 produced the assembly

	.type	Main_zdwwork_info_itable,@object # @Main_zdwwork_info_itable
	.section	.rodata,"a",@progbits ; note .rodata, not X98A__STRIP,__me3!
	.globl	Main_zdwwork_info_itable
	.align	16
Main_zdwwork_info_itable:
	.quad	(S2ZH_srt$def-Main_zdwwork_info$def)+8
	.quad	4294967299              # 0x100000003
	.quad	0                       # 0x0
	.quad	4294967311              # 0x10000000f
	.size	Main_zdwwork_info_itable, 32

At first I thought this was an LLVM bug, but after reading http://llvm.org/docs/LangRef.html#linkage-types I'm not sure; maybe the internal linkage type means that @Main_zdwwork_info_itable$def is just a constant value without any "identity", so the LLVM optimizer is free to drop it, merge it with another constant, or move it to another section?

One workaround would be to use external linkage for these foo_info_itable$def symbols, and then if desired (to reduce symbol table size), strip out any .global bar$def statements in the LLVM mangler...?