Binlex do not capture all the basic blocks from the function

[vmovupd]

Description:
In some cases, when processing a function and creating a JSON for that function with capstone disassembler (x86) in Binlex, the resulting JSON does not contain all the basic blocks from the original function.

To Reproduce:
The first function's bytes (architecture i386):
558bec5657668b7d0c33f6833d88cc4300020fb7d77d2a8b4d088bf1668b0183c1026685c075f583e9023bce740966393975f48bc1eb6733c06639110f44c1eb5d8b5508eb110fb702663bc70f44f26685c0744883c2028d4201a80e75e833c0663bc7751eb80100ffff660f6ec8eb0383c2100f1002660f3a63c81575f28d044aeb1b0fb7c7660f6ec0660f3a63024173038d344a740583c210ebee8bc65f5e5dc3

The control flow from Cutter:

After processing with Binlex and concatenating the bytes from each block, the resulting string is shorter:
558bec5657668b7d0c33f6833d88cc4300020fb7d77d2a8b4d088bf18b5508eb110fb702663bc70f44f26685c0744883c2028d4201a80e75e833c0663bc7751eb80100ffff660f6ec8eb0383c2100f1002660f3a63c81575f28d044aeb1b0fb7c7660f6ec08bc65f5e5dc3

The control flow from Cutter for Binlex output bytes:

Second function's bytes (architecture i386):
558bec83ec245356578bf98bda33c9895df4894df88b573c8b743a7803f78b462403c78945ec8b462003c78945f0f7c30000ffff752a0fb7cb3b4e100f821a0100008b46140346103bc80f830c0100002b4e108b461c8d04888b0c3803cfeb6633d2394e18765c8b049003c78a0b3a08884dff8b4df87522384dff74198a4b013a4801884dff8b4df8750f83c30283c002384dff75d633c0eb051bc083c80185c0740e8b5df4428b45f03b561872b8eb128b45ec0fb70c508b461c8d04888b0c3803cf8b573c3bce0f82870000008b443a7c03c63bc8737d51e83f2201008bf05985f674776a2e56e840fd00008bf8c745de622e0d035933d2c745e2062e0b00598817b162c745e61003101b8bc266c745ea2300304c05df4083f80c73058a4ddeebf18855ebe892feffff8d55df8bc8e8cbfeffff85c0742356ffd0568bd8e82d2201005985db74138d57018bcbe8adfeffff8bc88bc15f5e5bc9c333c0ebf7

After processing with Binlex and concatenating the bytes from each block, the resulting string is again shorter:
558bec83ec245356578bf98bda33c9895df4894df88b573c8b743a7803f78b462403c78945ec8b462003c78945f0f7c30000ffff752a0fb7cb3b4e100f821a0100008b46140346103bc80f830c0100002b4e108b461c8d04888b0c3803cfeb6633d2394e18765c8b049003c78b573c3bce0f82870000008b443a7c03c63bc8737d51e83f2201008bf05985f674776a2e56e840fd00008bf8c745de622e0d035933d2c745e2062e0b00598817b162c745e61003101b8bc266c745ea23008bc15f5e5bc9c333c0ebf7

The control flow graph is also different.

Expected Behavior:
Binlex returns all the basic blocks which are present inside the function.

Affected OS/Version:
binlex.exe for Windows from binlex-v2.0.0-rc2
Python binding from commit 5db0572 (before preparing for ARM disassembler, shouldn't affect x86 AFAIK)

P.S. The latest commits divide capstone disassembler on x86 and ARM (which will be in the future). However, when initializing a capstone disassembler (x86), it is required to pass architecture, so wouldn't it be better to choose ARM or x86 capstone based on the architecture in Binlex itself? With the current approach which modifies the API (binlex.disassemblers.capstone to binlex.disassemblers.capstone.x86), it would introduce unnecessary checks from the user side which can be avoided (as far as I understand tho).