Fix UI race when showing package count

[wagoodman]

Today we show package count on the UI to help the user get a sense of the progress during cataloging:

$ syft cgr.dev/chainguard/redis -o json=/tmp/redis.json                           
 ✔ Loaded image                                                                                                                                                     cgr.dev/chainguard/redis:latest
 ✔ Parsed image                                                                                                             sha256:b4eb9f8d974e79ce5ea8e8f42d9bd595c5c803f94cb0171148ff7f6586c92ec3
 ✔ Cataloged contents                                                                                                              e007b0d98c58812eb5244b38b535ea3133ac144f610800c5c903113b293ae6a1
   ├── ✔ Packages                        [17 packages]  
   ├── ✔ File metadata                   [402 locations]  
   ├── ✔ File digests                    [402 files]  
   └── ✔ Executables                     [81 executables]  

(note : Packages [17 packages] )

This value has been found to be inconsistent with the final package count, on subsequent runs showing different values for the same input:

Packages                        [19 packages] 

In this particular circumstance two packages identified by the binary cataloger were removed since a more authoritative package type supersedes the binary packages.

The current implementation that tracks package count that drives the UI polls in the background. Ideally the the package count should be event driven when added to the collection, however we don't want bus interactions to be embedded into core objects. For this reason this PR adjusts the package account to be event driven within the internal SBOM builder object. The specific change is to add onWrite callbacks that can be provided to the SBOM builder, in which a callback function that updates the monitor object on any write to the SBOM.

Fixes #2304