Class `Alert` doesn't store any provided information

[Byloth]

As briefly described in the Issue #9, Vuert allows the developer to extend the options provided (among the default ones) when emitting a new alert.
Or, at least, it should do so... In reality, it isn't like that.

In the constructor of the Alert class, the options are -indeed- selected one by one and assigned to the Alert object.
What happens if the developer adds some new properties? They're simply ignored and lost.

Should it just use the payload property that accepts any kind of data?
What if I want to provide some data to the AlertHandler but not to any eventual custom child component?

[Byloth]

Picking this up after the work on #9.

With the augmentation pipeline now propagating correctly through AlertOptions and all its leaf types (SimpleAlert, CustomAlert, BlockingAlert, DismissibleAlert, BlockingCustomAlert, DismissibleCustomAlert), and with the same pattern extended to ActionCustomOptions for ActionOptions / CallbackAction / ValueAction, this issue has gained a second dimension worth tracking alongside the original one:

1. Runtime (the original problem): the constructor in models/alert.ts only copies a fixed allowlist of known fields (type, priority, icon, title, …); any property added through an AlertCustomOptions augmentation is silently dropped. The same applies to models/action.ts for ActionCustomOptions.

2. Type-level (surfaced by AlertCustomOptions doesn't work properly #9): even if the constructor did forward every property, the class declares each field with its base type (e.g. readonly icon?: string) and implements IAlert<R, P>. IAlert was deliberately left as the runtime contract — interface augmentation can't change a class's declared property types — so reading instance.icon on a constructed Alert always reports the base type regardless of how the consumer augmented AlertCustomOptions. Same for Action.

Two design choices to make together:

• How to store the augmented surface at runtime. Options: Object.assign(this, options) for unknown keys; keep the explicit allowlist and document augmentation as "input-only"; expose extras through a dedicated container distinct from payload (since the question raised here — "what if I want data for AlertHandler but not for the custom child component?" — points at a separation between handler metadata and component payload).
• How to expose the augmented type on the instance. The implements IAlert<R, P> shape constrains the class. To let consumers read instance.icon as MyIconDefinition (after their augmentation), the class would need to be exported with a derived public type (e.g. a WithCustomOptions<IAlert<R, P>>-shaped facade) rather than the raw class type. Same for Action.

Resolving both together — runtime storage + type-level instance shape — would close the loop the augmentation feature was designed to provide.