Multiple onNotification/onRequest registration

[dhuebner]

Fixes #63

Registering overlapping onRequest/onNotification handlers previously failed silently
(webview side: last registration wins, dispose() could remove the wrong handler) or only
surfaced as a runtime dispatch error (host side: "Multiple matching request handlers").

This PR enforces handler invariants at registration time on both sides:

• Kind homogeneity: a method must be used exclusively for requests or notifications;
  registering the opposite kind throws immediately.
• Request uniqueness per scope: a second onRequest for the same method throws if its
  sender scope overlaps an existing one (host side); the webview side allows at most one
  request handler per method.
• Notification stacking: onNotification still stacks freely - all matching handlers fire.
• Disposable.dispose() removes by identity, not by method name, so stacked notification
  handlers can be managed independently.

See ADR-0004 for the full design rationale
and breaking-change notes (shipped as a minor version bump under 0.x SemVer, v0.7.0).

Also includes: ADRs 0001-0003 documenting prior design decisions, updated ARCHITECTURE.md,
new vscode-messenger-common/src/util.ts for shared participant/error-message helpers, and
expanded test coverage for the new registration-enforcement behavior on both host and webview
sides.

[jonah-iden]

Looks pretty good to me.
I guess registering a handler first for notification and request can only happen if you don't define your message types correctly beforehand right? Otherwise it would already be catched at compile time. But still good to have that extra security.
documentation also looks pretty good to me