Fix endianness bug when indexing into OpenQASM classical types

[orpuente-MS]

The following list of conclusions gathered from the OpenQASM spec will be useful while reviewing this PR. You can find this information in the official OpenQASM spec.

1. Bitstring Literals are written in big-endian order.
   The spec says: "For convenience, classical registers can be assigned a text string containing zeros and ones of the same length as the size of the register. It is interpreted to assign each bit of the register to corresponding value 0 or 1 in the string, where the least-significant bit is on the right."

2. Bit indexing of bit arrays literals is in big-endian order.
   The spec says: "classical registers are static arrays of bits."
   So, when doing bitarray[0] we are accessing the first element of that "static array", the leftmost element, which according to (1) is the most significant bit. Therefore, indexing of bitarrays is in big-endian order.

3. Bit indexing of int, uint and angle is in little-endian order.
   The spec has this example where they hint that given int[32] myInt = 15;, myInt[0] evaluates to 1, that means that the least significant bit is stored first, and indexing of int, uint, and angle is in little-endian order.

4. We index classical types by first casting them to bitarrays, which are in big-endian order, therefore when doing myInt[0], we need to do bit[32](myInt)[31]. Note that we transformed the index 0 into 32 - 0 - 1 = 31, effectively changing the endianness of the indexing operation.

[github-actions]

Change in memory usage detected by benchmark.

Memory Report for eb6baf8

Test	This Branch	On Main	Difference
compile core + standard lib	25361838 bytes	25361638 bytes	200 bytes

[github-actions]

Change in memory usage detected by benchmark.

Memory Report for 59c9d25

Test	This Branch	On Main	Difference
compile core + standard lib	25361838 bytes	25361638 bytes	200 bytes

[swernli]

Changes look good to me, with the usual caveat that endianness switches are always tricky and nuanced.