Consider capturing more location information

[smeenai]

As discussed in llvm/llvm-project#113483, if we see a future need for it (e.g. for debug information or diagnostics), we can consider including more information in the mlir::Locations we create, e.g. to capture macro expansion information. We could potentially use an OpaqueLoc attribute for this that includes the original SourceLocation or create our own location attribute that wraps a clang SourceLocation (if we need full serialization/deserialization). There's no action needed here right now, I'm just creating this for tracking.

[bcardosolopes]

Using lists of fused locs isn't great indeed (unpacking it will always be a guess game), one example is the IfOp which right now might have a list of 4 locs (to track begin/end for both arms), we kinda infer what's that about. As you rightly pointed out, to do this right we need some layer of abstraction in the likely form of a new attribute.