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 and 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.