Fix plugin custom events never reaching native addEventListener listeners

[Salvialf]

Problem

Custom events emitted via event::add() that aren't in the core's hardcoded whitelist (scenario::update, ui::update, etc.) are dispatched exclusively through $('body').trigger() when jQuery is loaded, still the default today even though jQuery's future in Jeedom is to disappear entirely. jQuery's trigger() only invokes handlers bound through its own .on()/.bind() API, it never reaches a plain document.body.addEventListener(...) listener. Any plugin that has already migrated its event listeners to native vanilla JS silently stops receiving its own events, with no error and no clear symptom beyond "the listener never fires".

Fix

Add jeedom.vanillaEvents, an extensible array of event names that should be dispatched natively (dispatchEvent(new CustomEvent(...))) instead of through jQuery. Any event name not in this list keeps the exact current behavior (jQuery trigger() when available), so existing plugins relying on jQuery-based listening are unaffected.

A plugin can opt an event into native dispatch once its own JS listener has fully migrated to addEventListener, by pushing the event name into the list from its own script:

if (jeedom.vanillaEvents && !jeedom.vanillaEvents.includes('myPlugin::myEvent')) {
  jeedom.vanillaEvents.push('myPlugin::myEvent')
}

This is opt-in per event name, so migration can happen gradually across the plugin ecosystem instead of a single breaking switch for everyone at once.

Alternative considered

Fixes #3185 that proposes always dispatching both natively and via jQuery for every event. That would trigger any jQuery-based listener twice for the same event, since jQuery's own .on() already registers a native listener under the hood, and the two firings wouldn't even carry data the same way: the native dispatch exposes it as event.originalEvent.detail, while .trigger() delivers it as the handler's second argument, the convention jQuery-based plugin code actually expects.