Add debug info for labels to Odin

[tf2spi]

This is a PR that adds debug info for labels in the Odin compiler, so now labels attached to statements in general like if, block, for, etc., have debug info.

package labels
import "core:fmt"
main :: proc() {
        myloop: for i in 0..<5 {
                fmt.println("We have debug labels now!")
        }

        myswitch: switch true {
                case:
                        fmt.println("Debug labels on switches but not in cases")
        }
        myif: if true {
                fmt.println("Debug labels on if statements")
        }
        // etc...
}

This is useful because debuggers can discern the location of code given a function and label and do actions to it like putting breakpoints on it. It's less finnicky than line breakpoints when it comes to source code changes.

# This works on gdb and puts a breakpoint on the 'myif' label in the code above
b labels.main:myif

[tf2spi]

Additional comments:

The way this is done in LLVM is by creating and inserting a DILabel using DIBuilder. There's a bit of a hiccup, though... In C++, this is done via llvm::DIBuilder::createLabel(DIScope, StringRef, DIFile, unsigned, bool) and llvm::DIBuilder::insertLabel(DILabel, DILocation, BasicBlock). However, LLVM-C doesn't wrap and export these functions, so I had to declare these with their mangled names on POSIX and leave these functions unimplemented on Windows.

I've tested the code on Windows, Linux, and Mac OS and it compiles fine. However, I haven't tested all constructs like SOA for loops yet.

[tf2spi]

Note to self: llvm_label could be nullptr here? Although IIRC, LLVM uses new in a bunch of places and doesn't specify std::nothrow, even in the C API, so I think exceptions would kill odin before it returns nullptr anyways.

[gingerBill]

I do not want to change the LLVM-C API. It has to be whatever the official one is.

[tf2spi]

In retrospect, I now realize this is the more wise approach. Better to ask llvm-project to add a new C API that we can eventually use. This ORCv2/LLJIT issue is a fairly recent example of them adding the API fairly quickly when they detect a valid use case.