Add BC layer between @drupal/once and jQuery.once

Problem/Motivation

If code relies on a core jQuery.once call, with the move to @drupal/once that code might execute more than necessary

Steps to reproduce

This can happens is a piece of code in contrib relies on a call to once from core (or another module that switched to @drupal/once)

// Before
$(el).once('test')// => 1 element
$(el).once('test')// => 0 element

// Problem
$(el).once('test1')// => 1 element
once('test1', el)// => 1 element => KO

once('test2', el)// => 1 element
$(el).once('test2')// => 1 element => KO

// Expected
$(el).once('test1')// => 1 element
once('test1', el)// => 0 element
// OR/AND
once('test2', el)// => 1 element
$(el).once('test2')// => 0 element

Proposed resolution

Support ONLY
On pages where jQuery.once is loaded, calls to @drupal.once will also update the jQuery.once registry.
This covers the use case of core updating to using @drupal/once, but a module is still using jQuery.once and has expectations regarding the contents of the jQuery.once registry.

once('test2', el)// => 1 element
$(el).once('test2')// => 0 element

Calls to jQuery.once will not update the @drupal/once registry
This would effectively be providing two-way compatibility instead of backwards compatibility. A module using @drupal.once should not have functionality that depends on jQuery.once usages or its registry. jQuery.once and @drupal.once can still be used simultaneously - but @drupal.once will intentionally not take jQuery.once's registry into account when determining if something has been "onced". After updating code to use @drupal.once, it should be confirmed any reliance on other module's use of "once" are ones also using @drupal.once.

$(el).once('test1')// => 1 element
once('test1', el)// => 0 element

In this case work with upstream to make them use @drupal/once or stick with using jQuery.once() until it is updated.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet