Add/remove/replace/info commands added to wbn-sign CLI

[rferens]

Summary
This change refactors the core signing logic into a new high-level SignedWebBundle API, introduces support for multiple signatures

Key Changes

• New SignedWebBundle API: Introduced a central class in src/core/signed-web-bundle.ts that provides a simplified, high-level interface for creating, loading, and modifying signed web bundles. It supports:

  • Signing an unsigned bundle with one or more strategies.
  • Adding or removing signatures from an existing signed bundle.
  • Retrieving the Web Bundle ID (App ID).
  • Loading signed bundles directly from bytes.

• Enhanced Integrity Block Management:

  • Moved IntegrityBlock to a dedicated core module and added the ability to parse existing integrity blocks from CBOR.
  • Refactored IntegrityBlockSigner to be internal, deprecating several methods in favor of the new SignedWebBundle and utility functions.

• Infrastructure & Utilities:

  • Added new utility functions for identifying pure vs. signed bundles and verifying signatures.
  • Updated tsconfig.json to strip internal declarations from the generated types.

[zgroza]

So, essentially this whole class, including the normal .sign() is @internal, isn't it? (I mean, if the constructor is...)

I'd argue that this class should provide a clear interface to the callers: you create it using whatever arguments and then call sign(). But here we have SignedWebBundle calling .signInternal() (which looks like it should only be used from inside this class (and probably should be marked private)), why?

[rferens]

I'd like to have this class internal, but for backward compatiblity(BC) it cannot be at least now (however I think about making it @deprecated now and @internal some day later, when almost no one uses old API.)

Regarding SignedWebBundle using .signInternal - yeah, I though 'internal' for package-internal, not class-internal, but perhaps its just my mistake. as the convention is probably what you suggested. I just created signInternal to be used by SignedWebBundle, which do not do not necessary step like forming Cbor or concatenating to create singeWebBundle.
Again, BC make things harder - the sign method should just return a new integrity block, but because of BC cannot. What do you think about deprecating sign (to change output format one day, when its internal) and renaming this method returning IntegrityBlock (that should be named 'sign')) sth like ' signAndGetIntegrityBlock()'

[zgroza]

Why then leave this here? The whole class has been removed from exports, so removing things from here instead of deprecating will not break anything (more).

[rferens]

The class was not removed from exports. It's kept for backward compatibilty. @deprecated is not a perfect tool for what I want to achieve, but good enough. I want to :
-use some methods still internally
-discourage users from using it externally, but

• do not break their current code, but introduce unpleasant warnings