more relaxed checking contexts synchronization

Only context's events_id and current_block_num are decisive for a
context views and application tables state. This two parameters
+ events queue content determines where the context will
move during calling app_next_block, other parameters like
irreversible_block, fork_id and back_from_fork depends only on them.

is_attached and detached_block_num must stay to ensure that all contexts
will got the same current_block_num and events_id after re-attaching.

note: irreversible_block and fork_id are initialized during context creation
to prevent removing reversible data and events not needed by the
rest(already existed) contexts when hived will signal new irreversible
block before new contexts will be moved with app_next_block. It
caused contexts synchronization exception when between creatig new
contexts a new event was signaled by hived, and then the contexts were
used within the same group.