Add uniqueId option to prevent duplicate/flooding notifications

[sorambr]

Why

I built this for my own RedM server: some of my scripts could resend the
same notification many times in a short window (a warning that re-checks
every tick, a chamado list refresh, etc.), and it just stacked toast after
toast on screen. I ended up adding an opt-in uniqueId to fix it, and
decided to share it here in case it helps someone else's server too.

What it does

Pass an optional uniqueId in the notification options. While a
notification with that same uniqueId is still on screen, resending it
only refreshes the visible title/description/icon instead of stacking a
new toast — duration and progress keep running untouched, so a resend
can't restart the bar or extend the toast's life indefinitely. A new
toast only shows up once the current one has naturally ended.

Without uniqueId, behavior is unchanged — fully backward compatible.

Also fixes

Found two bugs while building this:

• notificationId was always overwritten with a random value, so a
  caller-provided id was silently dropped — it never actually worked.
• the NUI used parseInt(options.id) to key notifications, which broke
  any non-numeric id.

Demo

Same test command spammed 10x in a row, first without uniqueId then
with it (console log at the bottom shows every attempt actually firing
either way):

• First half (no uniqueId): stacks a toast per call.
• Second half (uniqueId set): stays a single toast even though the
  command still fires 10 times.

Testing

Added /bln_notify_flood as a usage example. Tested in-game on my own
server: without uniqueId a burst of sends stacks N toasts (the bug);
with it, only one toast stays on screen and its content updates live.