Fuse tight composer

@bronevet 
Greg
 The idea behind this method is the following. All queries Expr2any or OperandExpr2Any queries to the TightComposer are translated into list of queries. List of queries because different part edges from getOperandPartEdge. We get a list of queries as input this method. The queries are also marshaled simultaneously into different query states. The different query states are init, analysis (when the query has been dispatched to an analysis) and finish. The list of queries are checked for if they are recurrent. Note that queries are marshaled simultaneously. So even if one of them create a cycle by forwarding the query back to the composer, all of them would be in the same state. If the queries are recurrent Full object is returned. If not the queries are all initialized and dispatched to individual analysis. So at line 189, you can see that the analysis' Expr2Any method is invoked. We dispatch the query for each analysis and for each PartEdge and for each analysis the results are combined using Union/Intersect objects. Finally these Union/Intersect objects are added to Mapped abstract objects corresponding to each analysis. This collection is a simply a list. We discussed last week as to why a list would be sufficient. The only problem though is that the line 189 can return Full objects which means the list will be not be aligned and we cannot do indexed item comparison (i.e., first item with first item etc.) We should not be storing any Full objects in this list. However the two list objects will contain the abstract objects from the same analysis. The change we have to do is to replace the indexed item comparison with item by item comparison. This will square the complexity but can be useful. 

What do you think?