Re-calculate toolbar's height every time when the viewport changes

@huzooka,
I want to fully test this out, but I think issue 1 needs more exact details about how to reproduce. "Toolbar adds an unnecessary top padding to body if the toolbar itself is unorinted (below 16.5em viewport width)". viewport width 16.5em isn't an exact number & needs detail about how to reproduce. Maybe just a screen shot of the issue here would be best.

Does fix the issue with padding on very small viewports.

Need to replace :visible by something else, we don't want jQuery specific selectors. or at least move it outside the main selector and add .filter(':visible').

Should use the getter to access isOriented value, any reasons to access it directly?

I have an issue with calling updateheight from adjustPlacement.
We have update height => trigger offset update => offest update trigger adjustPlacement

Actually I'm not quite sure why we're computing the height from the toolbar. There is code in Drupal.displace that does the job already. Doing this fixes the bug too:

      // Trigger a recalculation of viewport displacing elements. Use setTimeout
      // to ensure this recalculation happens after changes to visual elements
      // have processed.
      triggerDisplace(propagate) {
        _.defer(() => {
          $('body').css({
            'padding-top': Drupal.displace(propagate).top,
          });
        });
      },


// later in adjustPlacement:

        this.triggerDisplace(false);

Removing all the code for the height computation and keeping only the call to triggerDisplace works too. Might break something but it's not obvious.

Take HEIGHT from `.toolbar-tab` but not their parents prevent the flickering. (Although it has broken by other commits again very quickly after my fixes)

So that, adding `'change:mqMatches'` to the below line is better (if we only want to trigger `updateToolbarHeight`):
https://git.drupalcode.org/project/drupal/-/blob/9.2.x/core/modules/tool...

Virtually, you will fall into the above conditions, so I bet this issue has another problem I overlooked? eg. multiple lines on another issue? (I loaded Claro theme and can't see any special changes required in this patch)

EDIT:
BTW, To fix these kinds of Toolbar issues, we must define the default behaviors of Toolbar. Otherwise, the fixes are non-stop.

Re-roll for 9.4

The Toolbar Module was approved for removal in #3476882: [Policy] Move Toolbar module to contrib.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3484850: [meta] Tasks to deprecate Toolbar module and the removal work in #3488828: [meta] Tasks to remove Toolbar module.

Toolbar will be moved to a contributed project before Drupal 12.0.0 is released.