Python names for LLVM values/types inconsistent

[pnwamk]

It looks like the constructor names for LLVM values and types in the python interface don't really have a consistency to them =\ IMO we should address this soon and then stick to whatever naming pattern we prefer.

Options:

1. Use a consistent suffix for each, e.g., NAME_val and NAME_ty (pros: simple, predictable; cons: a few additional characters here and there)
2. Use no suffixes, but places values and types in modules which can be imported with whatever prefix is desired (pros: flexible, users decide prefix to import with (if any); cons: val.NAME and ty.NAME might look funny, if no prefix is present from the import it may be difficult to determine meaning from code).

[RyanGlScott]

I think (1) is closest to my ideal, although I don't think we need to use the suffixes for every definition. For instance, I think global_var is fine as it is, and global_var_val would just be unnecessarily redundant.

[pnwamk]

Fixed by #1168