* Fix(#5328): Layers Control scrollable even if collapsed: false
the `expand()` method was called only when expanding the Layers Control through user action.
In the case of option `collapsed: false`, no event listener is attached (no user action expected to expand), therefore the control height is no longer adjusted compared to map container's height, whereas the only time it is done is at initialization, when the control is not yet inserted into the DOM, hence it does not have an actual height to check against.
Therefore added a hook on `addTo()` in order to run `expand()` AFTER the control has been insterted into the DOM.
The same issue happens when later adding more base layers / overlays to the Layers Control: it not collapsed, we should run again the height check (e.g. through the `expand()` method) to make sure we make it scrollable if necessary.
Therefore called `expand()` after each `_addLayer()`.
Actually checking first if the control is on map and if option `collapsed: false` in order to prevent calling `expand()` for nothing.
* Test(ControlLayers): 2 tests for collapsed: false being scrollable
(for issue #5328).
CAUTION: unlike most other tests, had to actually insert the map container into the DOM (i.e. `document.body`) for these tests to be useful, otherwise the height remains at 0.
This may lead to memory leak and tests hanging if done on too many tests (see Leaflet.markercluster tests issue, e.g. https://github.com/Leaflet/Leaflet.markercluster/pull/577)
Symptom: Switching between layers with different attributions does
not remove the attribution from the previously selected layer.
Control.Attribution keeps track of its attributions with a counter for
each text. The problem described in #4285 is that each time the layer
is added to the map, the counter is increased by two. It's because
Layer calls Control.Attribution.addAttribution() twice, once from
addLayer() and the second time via the whenReady() callback _layerAdd().
This was not caught by the tests since the callback was never fired
(missing map.setView() call).
Fixes#4285
The rationale is this: the spec string describes the expected
behavior unconditionally. The code examples, on the other hand,
set up an expectation that is tested with the call to the expect
method. The code examples can violate the expectation, but the
spec string does not. The value of the spec string is as clearly
as possible describing the behavior. Including “should” in that
description adds no value. (From http://rubyspec.org/style_guide/)
