harmonize code paths used in FastBoot and non-FastBoot of <BsModal>

[jelhan]

Running same code paths in FastBoot as in "regular" environment reduces the risk of bugs. To do so I moved the guards for FastBoot as close as possible to the places in code, which access document or window. Tests are passing and I manually verified that /fastboot/modal URL of dummy app shows the modal even with JavaScript being disabled. Not sure if additional manual tests are required.

Another small refactoring pulled out of #1402.

[simonihmig]

As much as I loved the previous round of refactorings, I am actually not so sure about this tbh.

If the concern of a function is to do something which does not make any sense in a different context, I don't think that function should be responsible to do the check, rather it's the caller's responsibility.

That applies at least for the scrollbar stuff for example, where we are not doing something that creates markup like adding a class (which would also apply to FastBoot), but manipulation DOM properties. Static HTML markup (like a string of HTML, which FastBoot effectively generates) does not know about scrollbars, so why should scrollbar-related functions need to take these environments into account?

So idk, I don't feel super strong about this, just some mild concerns/questions...

[jelhan]

Main driver of the refactoring was to run show method in handleVisibilityChanges and not skip it early. Mostly because that relies on modal being opened in a different way than through show method. Basically the coupling of internal and external modal state, which I tried to address in #1402.

Not sure if I have any opinion if setScrollbar should guards against FastBoot or if the caller should do so. Happy to refactor to something like this if you prefer:

async show() {
  // ...

  if (!isFastBoot(this)) {
    this.checkScrollbar();
    this.setScrollbar();
  }
  
  // ...
}

[simonihmig]

Not a big deal as I said, but yes, I would slightly prefer that...