AdminUX Patch and Admin Page

[KyrneDev]

Fixes #2498
Fixes #2503
Fixes #2504
Fixes #2520

Changes proposed in this pull request:

• Add an AdminPage component that all admin pages extend. It contains the buildSettingsComponent helper and a few other helpful save functions.
• buildSettingsComponent now assigns attrs to the components it is building (min/max/classname etc). Also allows built in helptext.
• Add padding to the bottom of extension page for permissions
• Remove AdminLinkButton (breaking/deprecated), AddExtensionModal, and app.extensionSettings. Drop support for SettingsModals for extensions.
• Prevent scope changes and allow horizontal scrolling from the extension permissions grid.
• Split ExtensionWidget functions of JSX.
• LESS despecifications.

Reviewers should focus on:
AdminPage, specifically the info section. Is this how we want to do it or do you have any better ideas?

Confirmed

• Frontend changes: tested on a local Flarum installation.
  Required changes:

• Related documentation PR: Will put docs PR when I make it

• Related core extension PRs: Tags: Max-height for tags settings tags#116 and English: AdminUx lang-english#183

[dsevillamartin]

This PR is a bit hard, there's many changes that address different things.
I do have a few things to point out and/or ask about.

I think we want methods for the options in info() instead of returning an object.

Why were fields removed in BasicsPage and MailPage? I don't see a reason given in the PR description.

[askvortsov1]

Overall makes sense, left some code nitpicks. Will test locally later.

Going forward, it would be preferable to split big changes like this up into commits (or even better, separate PRs when possible) to make review easier.

[KyrneDev]

I think we want methods for the options in info() instead of returning an object.

Like icon() and description()?

Why were fields removed in BasicsPage and MailPage? I don't see a reason given in the PR description.

There's no need for them as there is a settings helper already apart of AdminPage now.

@datitisev

[dsevillamartin]

Like icon() and description()?

Yes, that's what other components do. This was just a thought by the way, but I feel like it'd be more intuitive than returning an object. If we wanted a simple info() method we'd probably create a separate class that encapsulates it, I think (or maybe I'm not making sense).

[SychO9]

I like this, it makes the interface so much more customizable!

[KyrneDev]

@datitisev I'm mostly in favor of keeping it inside one function and return an object. I think having functions for all four info items is a bit redundant and although there will have to be a certain level of redundancy this takes up the smallest footprint. It's just as easy to extend as well.

Let's keep discussing! For now, I'm going to just change it to headerInfo

[askvortsov1]

Could any of the CSS common across pages be factored out into an AdminPage.less file?

[SychO9]

@askvortsov1 there are some pages like Basics, Appearence and Email, that have similar bottom padding and container CSS code, but it's also different in Dashboard, ExtensionPage and PermissionsPage, so I don't think we could

[SychO9]

Looks good to me!