feat: #2785 - async access to dao product list

[monsieurtanuki]

Impacted files:

• all_user_product_list_page.dart: split in a not-loaded / loaded version; computes each user list length with a FutureBuilder
• continuous_scan_model.dart: minor refactoring
• dao_product_list.dart: switch from "box" to "lazyBox" in order to cleanly make all methods async
• new_product_page.dart: now loading lists with FutureBuilder
• product_list_page.dart: minor refactoring
• product_list_supplier.dart: minor refactoring
• product_list_user_dialog_helper.dart: now explicitly calling notifyListeners as setState won't be enough because of pre-loaded data
• query_product_list_supplier.dart: minor refactoring

What

• It's the first step of Upgrade of product list key, allowing for more search parameters #2785
• The goal here is to convert the hive "product list" box to a "lazy box". That means that no data is pre-loaded at init time, and that all access to data is async.
• A side effect is that the app init will be faster (as long as all the list load can be).
• But the main goal is to prepare the rest of Upgrade of product list key, allowing for more search parameters #2785, where we'll use sqflite, which has a behavior similar to hive's lazy boxes - very fast init, no pre-load and async access.
• Therefore, when we switch to sqflite, we won't have to worry about async accesses - it's already done here. Less impact on less files, which is easier to review ;)
• We are even virtually ready to switch to sqflite now. That wouldn't be a great idea because we should deal also with the "bigger primary key" feature, in order to migrate at the same time enhanced primary keys and hive-to-sqflite.

Part of

• Upgrade of product list key, allowing for more search parameters #2785

[VaiTon]

I would invert the if so that we do the "heavy lifting" outside the if branch

[VaiTon]

I would invert this if for readability

[monsieurtanuki]

Thank you @VaiTon for your review!

I would agree with you about the position of ifs and elses, but in this case we're talking about 5-line code with no ambiguity: if (x) {return y;} return z;.
In addition to that I prefer && that is more straightforward: most of the time I bug then I have to rewrite my conditions if there are || and ! here and there.
That said, I hate when the code inside the if is so long that you totally forgot what you were testing in the first place. I try to return ASAP.