New timing for generating refinement constraints

[d367wang]

Originally the refinement constraints (i.e. equality constraint of form "refinement var == rhs value"), are created in InferenceVisitor.commonAssignmentCheck. This leads to the hack of overriding the LHS type with the refinement value in the dataflow transfer function, which is misleading.

To avoid hacking, PR #314 change the timing for refinement constraint generation when the LHS is declared type, from InferenceVisitor.commonAssignmentCheck to InferenceTransfer.visitAssignment. In other word, we create equality constraint once a new refinement variable is created.

The benefit of this change is that the type inference and type checking are unified in one single type rule:
LHS <: RHS.

Another benefit is that for posfix-increment/decrement expression specifically, it saves the work of caching the pre-state of increment/decrement and retrieving it when creating constraints. The logic becomes concise and straightforward for x++:
refinement constraints are naturally created along with the dataflow analysis so that no caching-retrieving is needed.

PR #314 doesn't handle the cases when LHS is type variable or wildcard, since type refinement in CFI is still unsound. We will finally handle this in the same way as above.