Add llvm_struct_type, llvm_packed_struct_type, and llvm_alias

[RyanGlScott]

This PR contains two commits that fix #1085. The first commit, which introduces llvm_struct_type and llvm_packed_struct_type, is straightforward. The second commit, which introduces llvm_alias and makes llvm_struct a synonym for llvm_alias, is slightly more involved, as it replaces all uses of llvm_struct with llvm_alias. llvm_struct is not deprecated in favor of llvm_alias yet, but we may wish to do so in the future.

[brianhuffman]

This all looks good to me.

Just to be clear: This PR leaves the lifecycle status of llvm_struct as Current; it has not yet been officially changed to Deprecated, which would restrict the use of llvm_struct without the enable_deprecated command. I think this is the right choice at the current time; we can officially mark the command as Deprecated after the next release version of saw.

[RyanGlScott]

Oh, I wasn't aware that there was a separate Deprecated constructor! I just looked at the crucible_* functions for inspiration, and since they all use Current, I went with that.

I worry now that I might be conveying mixed messages, since I explicitly use the word "deprecated" in the changelog. What is a better way to describe the new status of llvm_struct?

[RyanGlScott]

What is a better way to describe the new status of llvm_struct?

For inspiration, I decided to see how the changelog handled the renaming from crucible_* to llvm_*. There, the changelog manages to avoid mentioning the word "deprecate" by simply stating that the crucible_* functions will continue to be available for the time being. That's a nice rhetorical trick, so I have pushed an update which adopts similar wording for llvm_struct/llvm_alias.

I think this is ready to go now, so I'll optimistically apply the ready-to-merge label.