some clarifications in README
tracking all dereferences in combined analysis

+ 276 @NotNull method annotations for jdk7-45
towards nullity constraints: state with constraints
towards nullity constraints: insnIndex of origin as identity

Interesting values (`null` and calls) have origin now - it is an index of instruction where they were born.
towards nullity constraints: (dummy) set of dereferenced vals

InOutConstraint: new `dereferenced` field - to keep dereferenced vals
one more iteration: tracking dereferenced vals
using constraint with dereferenced values

In current iterations such constraint is used only for methods without cycles.
(It is unclear currently for me how to handle generalization for constraints)
parameters in result origins as well
track dereferencing of parameters
track all possible result values
tracking all comparisons with null
delta in test data (@NotNull)
refactoring Actions/States of analysis

moving concrete Actions and States into corresponding modules
simplification of Nullable parameter analysis

Instead of detecting that a parameter was passed into interface call, we can deduce NPE directly in interpreter.
no need to track `taken` during OutAnalysis

really we need `taken` only to handle `throw ...` during parameter analysis
comment
more granular measurements of time
how many origins?

It turns out that for for almost all methods the number of all origins < 32. It means that corresponding constraints can be encoded via int - each origin can be encoded via corresponding bit mask
comments for result origins analysis
micro-optimizations of resultOrigins analysis