Blockpc

This patch addresses issue #81 by implementing blockpc based on Peter's
suggestion. blockpc has the same semantics as pc, except that pc only applies
when the given predecessor of the given block is chosen.

blockpc(s) are collected in a way similar to what we currently do for pc(s),
and are encoded with a similar technique for encoding UB constraints.

The parser is also updated to parse blockpc(s).

I am sorry the path is a bit big...

If a predecessor produces zero predicates, then with the current approach, we just don't generate blockpcs for the BB (or should we?). My understanding is that if predicates on a predecessor are missing, then we have incomplete info about the incoming branches and don't want to produce blockpcs in this case. Maybe I am wrong. 

Can you elaborate on the case where a predecessor produces more than one predicate? I am not sure if I understand it. Maybe you mean all predicates collected along the path of predecessor->predecessor->...? If this is the case, then it should be handled. For example, in the previous example, the blockpcs generated for instruction %i will include:

blockpc %B4, 0, s1, r1 // B1->B2
blockpc %B4, 1, s2, r2 // B8->B3
blockpc %B7, 0, s3, r3 // B4 -> B5
blockpc %B7, 1, s4, r4 // B9 -> B6