Make assembler work better with code that issues *cblock opcodes.

[jannotti]

If a program has an explicit intcblock or bytecblock, the pseudops int and byte respectively have strange behavior.
The following program

        intcblock 2 3
        int 5

is assembled as:

#pragma version 1
intcblock 2 3
intc_2

Which will fail at runtime because the constant reference is beyond the constant block.

We could assemble pseudo-ops to the push form is they use a constant that is not in the user suppled constant block.

A slightly different problem. This program:

        intcblock 2 3
        intcblock 4 10
        int 5

somehow gets assembled to:

#pragma version 1
intcblock 2 3
intcblock 4 10
intc_2 // 4. (this disassembly is quite strange)

it's hard for me to guess what's going on. But the the 5 is again not going to work, as no intcblock is long enough for an index of 2.

We should probably use push* exclusively for the pseudo ops when two constant blocks appear. Presumably this would only be done by a clever compiler to TEAL, and it would use the intc,bytec ops explicitly to take advantage of its clever constant block usage.

A final problem, related to fixing the last problem. There are reasonable proposals to place a constant block at the end of programs as a place to put program metadata. It would be nice if doing so did not prevent the usual pseudo op assembly. That is, even though such programs have an explicit constant block, the normal assembly operation is fine.

[jannotti]

I now understand the problem and have a limited solution. The int pseudo op should mostly not be available if there is an explicit intcblock in the program. For one thing, there is the existing bug, in which the int pseudo op believes it can append to the the manual cblock, but it can not, because we do not modified explicit cblocks in TEAL source. Further, there are weird cases in which it's not even possible to know which cblock is in effect when a given instruction executes. So I advocate banning int in combination with intcblock. However, as a concession to some pending standardization efforts that are considering the use of the constant blocks as a way to convey metadata information about a program, we should try to allow "harmless" cblocks - for example, if a cblock is in deadcode, it can't cause problems.

(All of this is equally true of int constants and byte constants)