Optimize block management in decode phase

[xiaohajiayou]

In #71 #66 #65 #30 , there were questions about the timing of applying can_append and may_append for requesting new blocks. This PR will separate the logic for appending new blocks when the block is just filled, and the hash check when the block is not fully filled, in order to improve readability.
Key Changes:

1. Call check_and_update_hash before processing each sequence
2. Replace may_append with append for clarity
3. Simplify conditional logic for better readability

(Addresses: Decouple block management and hash computation)

[xiaohajiayou]

In #71 ,Combine the logic of block allocation and hash calculation into an atomic operation.
It seems that both methods are feasible, but there is a slight difference in how they improve readability:

Method 1: Pre-allocation Principle (len (seq) % self.block_size == 0)

This ensures that memory blocks are pre-allocated in exact multiples of the block size, making the logic relatively intuitive to understand. However, in practice, it still needs to enter may_append for runtime hash checks.

Method 2: On-demand Allocation Principle (len (seq) % self.block_size == 1)

Separate the responsibilities of block allocation and hash checking. Split can_append and may_append into can_append、append, and check_and_update_hash, thus keeping the block allocation logic decoupled from the hashing process.

[CZWin32768]

Hi, thanks for your fix. I have a question: your impl of check_and_update_hash assert the last block hash always being -1. Is there situation that the previously preempted seq length equals block size so that the hash is not -1?