Add more detailed description to the panic message

[semisemisea]

After spending a month building my compiler, i've now finished the major part of this project(Chapter 1-8), with only some 'little' optimization work to do...

But I also noticed that most of the method, though describe the panic message in a very straightforward way, did not show enough information to quickly locate the source of bugs.

Examples:
1.thread 'main' (28378370) panicked at ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/koopa-0.0.9/src/ir/builder.rs:309:9:
argument type mismatch <----- I think at least we can the expected type and current type.

2.thread 'main' (28364503) panicked at ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/koopa-0.0.9/src/ir/builder.rs:209:14:
src must be a pointer of array. <----- I think we can show what type is src or what type src points to

I know this is the place where debuggers plays well, we can toggle some breakpoint and swimming in stack to find problem, but some informative warning message do not hurt.
So I am wondering would this project introduce some error handling library like anyhow or thiserror in the future?

Koopa IR and this whole course are very helpful and meaningful to me. I am willing to contribute at this part(Error reporting) in my spare time.

[MaxXSoft]

Thanks for your helpful suggestions!

Regarding panic messages: Detailed error messages are indeed very necessary, I'm going to spend some time to improve this part. And also I'm glad you're willing to contribute to this, feel free to open new PRs anytime.

Regarding error handling mechanisms: I chose to use panic instead of Result<T, E>, because koopa is a crate for compiler developers to generate IR, not a crate for handling user input. If there are some inconsistencies in the IR (e.g., type mismatches), it's developer's fault (he misused the API), and the only solution is to fix the code and recompile; therefore, there's no reason for the program to continue running. So this crate shouldn't return a Result type that indicates a recoverable runtime error.

[hsqStephenZhang]

for a supplementary to the runtime panic, is a verify function that verify the integrity of the IR necessary?

[MaxXSoft]

for a supplementary to the runtime panic, is a verify function that verify the integrity of the IR necessary?

@hsqStephenZhang This might be helpful for debugging. I think it's fine if the developer always has to explicitly call the verify function, but it shouldn't run implicitly in the background.