Asset cache reworked

[QubaB]

I prepared draft of assetCache upgrade, it works and is able to read already saved notes and also save newly created notes. I would like if someone test it. I tested it on Windows and Android and seems to work correctly.

Current implementation of assetCache, especially handling pdf files does not work correctly.

My code is not very polished, and it contains several unnecessary and inelegant parts (as I am not highly experienced in programming asynchronous applications). However, I hope it may serve as a useful starting point for considering how to adapt the current cache to ensure it functions correctly and efficiently with PDF files.

I also tried to ensure that notes created in the current version of Saber can be loaded. When reloading a note that contains a PDF and then saving it again, an asset is created for each page, each containing the entire PDF. This is why AssetCacheAll.addSync is particularly complicated and makes use of previewHash to identify many identical files using starting 100KB bytes and file size.

I tested this implementation on windows and Android (Samsung Galaxy Tab A7 lite). Both were able to display 850 pages pdf and note was loaded quite fast and pages are displayed almost instantly during listing pages.

Short description of current state of cache and my approach follows

Current cache and images problems:

two caches assetCache (for working), OrderedAssetCache (for writing)
keeping bytes of each asset in memory (I do not know if it is problem, but it is problem when adding to cache
because all bytes must be compared with each already added)
after first saving of note importing pdf, is pdf saved as one asset because:
1. importPdfFromFilePath create one File " final pdfFile = File(path);"
and this File is used to create all instances of pages
2. when saving, all pages are one asset, because File is the same object!!!
when loading note again and saving note, each page is treated as different pdf. Why? 
PdfEditorImage class
1. when reading fromJson is created "pdfFile = FileManager.getFile('$sbnPath${Editor.extension}.$assetIndex');"
for each page (even if they are the same asset file)
2. PdfEditorImage constructor is called with this File - each page has its own File!!!
1. OrderedCache.add adds each page as new asset because each page is different File
problems of PdfEditorImage
1. PdfEditorImage keeps bytes of the whole pdf (wasting memory) even if it renders only one page
2. creates its own pdfDocument renderer - for each pdf page is new renderer keeping whole pdf
3. while saving note is to the OrderedAssetCache added each page of pdf separately as new asset.

New approach to cache
Cache handles jpg, png, pdf, svg. All cache items are File.

For each photo item provides ValueNotifier<ImageProvider?>, so the same items have the same ImageProvider.
For each pdf item provides ValueNotifier<PdfDocument?>, so every page of pdf use the same provider.

During the reading of note to Editor are new items added using addSync - which is fast and synchronous
addSync method:

must treat duplicated assets (especially pdfs created by current version of OrderedCache)
it calculate fast hash from first 100 KB of file and file size, if hash is the same files are "identical"
this is important only for compatibility.

In Editor is used async method when adding new image
add method:
it compares first paths, file size and then hashes of all cache items
calculation of hash is very time consuming, it will be better for pdfs to extract /Info and read author, creation date, etc.
and use this to recognize different pdfs. It will take less time.

Cache properties:

Every cache item is created and treated as File (path). Even picked Photos are first saved as temporary files and then added to chache as File.
Each item provides PdfDocument for pdfs or ValueNotifier<ImageProvider?> for images. It saves memory.

When note is saved and some image is removed from note, asset files are reordered. If it happens their image of pdf providers must be changed. Especially pdf pages disappear for a while until new pdfDocument is opened - it can be solved, but I did not care now.

I believe the cache needs to be rewritten, as many users work with PDFs and the current version is not functional and cannot handle displaying PDFs with hundreds of pages.