CLAM-2353 Abort signature load for short signature patterns

[val-ms]

If a signature has a pattern that is too short will fail to load the siganture but does not cause the entire load process to abort. This is bad for two reasons:

1. It is not immediately apparent that the signature is bad, and so it could be published accidentally.
2. The signature is partially loaded by the time the bad pattern is observed and that may cause a crash later.

Because of (1), it is not worth it to try to unload the first part of the signature. Instead, we should just abort the signature load.

Fixes: #923

[m-sola]

Testing current main showed:

LibClamAV Warning: Don't know how to create filter for: Win.Downloader.LNKAgent-10001628-0
LibClamAV Warning: cli_ac_addsig: cannot use filter for trie
Loading:     0s, ETA:   0s [========================>]        1/1 sigs
Compiling:   0s, ETA:   0s [========================>]       40/40 tasks

AddressSanitizer:DEADLYSIGNAL
=================================================================
==18764==ERROR: AddressSanitizer: SEGV on unknown address 0x7fda0a808fff (pc 0x7fd910cad7ec bp 0x7fff45018270 sp 0x7fff45018200 T0)
==18764==The signal is caused by a READ memory access.```

After changes:

```../../bin/clamscan -d Win.Downloader.LNKAgent-10001628-0.ldb ./s00234-023-03120-1.pdf
LibClamAV Warning: Don't know how to create filter for: Win.Downloader.LNKAgent-10001628-0
LibClamAV Warning: cli_ac_addsig: cannot use filter for trie
LibClamAV Error: cli_add_content_match_pattern: Problem adding signature (1).
LibClamAV Error: cli_add_content_match_pattern: Problem adding signature (1b).
LibClamAV Error: cli_loadldb: failed to parse subsignature 2 in Win.Downloader.LNKAgent-10001628-0
LibClamAV Error: Problem parsing database at line 1
LibClamAV Error: Can't load Win.Downloader.LNKAgent-10001628-0.ldb: Malformed database
ERROR: Malformed database     [                         ]        0/3 sigs

----------- SCAN SUMMARY -----------
Known viruses: 0
Engine version: 1.2.0-devel-20230601```

Fix works great, no issues there.

And this is certainly an edge case, but does it make sense to *not* print the loading bar when we have a malformed db?

[val-ms]

@m-sola good idea. I just pushed up a commit that adds a check if success before trying to print that loading progress bar. This way it doesn't print overtop the error message.

While looking at that I also found that the same logic of adding a filter (and failing on a pattern < 2 bytes) exists for the Boyer-Moore matcher as well. I don't have a test case to demonstrate it, but it definitely needs to fail out if a signature fails to load. So I added a return CL_EMALFDB; there as well.

[m-sola]

Updated printout looks great!

[val-ms]

Marking as a cherry-pick candidate because while this isn't super critical, it's safest to backport the fix for 1.0 LTS.