riscv64: Implement ELF TLS GD Relocations

[afonso360]

👋 Hey,

This PR implements ELF TLS GD relocations in the RISC-V backend. This is required to get the rustc_codegen_cranelift's testsuite passing on this architecture.

The TLS GD model for RISC-V works slightly differently from the rest of the existing architectures. Usually you have 2 or 3 relocations pointing to a symbol and then a call to __tls_get_addr. RISC-V however has one relocation pointing to the symbol in a auipc instruction, and then a relocation pointing to a label in that auipc instruction, not the final symbol itself.

label:
    auipc a0,0                    # R_RISCV_TLS_GD_HI20 (symbol)
    addi  a0,a0,0                 # R_RISCV_PCREL_LO12_I (label)
    call __tls_get_addr@plt

This presents a problem as we currently don't have a way to export labels into the final binary, or a way to target labels with relocations.

Most of this PR is dealing with that issue. In the first commit I've introduced a notion of label visibility that allows a label to be marked as public, and if so, be carried all the way through to binary object emission.

Secondly is altering our allowed relocation targets. Currently we only allow external names, such as libcalls or other functions. I've altered this to allow targeting other labels within the function.

Only the final commit deals with implementing the TLS GD relocations in the RISC-V backend.

---

I also considered implementing TLS descriptors, but their spec isn't finalized yet (riscv-non-isa/riscv-elf-psabi-doc#94)

This doesn't have a great deal of tests as its quite difficult to test these kinds of binary emissions. But I've manually tested this by running cg_clif's testsuite.

CC: @bjorn3

[alexcrichton]

ELF bits all look good to me (in that I'm assuming you're checking correctness and otherwise can confirm they're idiomatic for Cranelift)

For the relocation/label bits I wrote out a suggestion below and am wondering if it can help simplify things a bit and keep MachLabel internal

[alexcrichton]

👍