[MIRROR] Function declarations in tgui [MDB IGNORE] (#25763)

* Function declarations in tgui (#80296)

<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->

## About The Pull Request
This PR is purely a style choice. We have a linter rule that enforces
expressions only, and I disabled it. If you're unfamiliar with JS, I can
explain the difference:

<details>
<summary>const vs functions</summary>

```tsx
// arrow function
const doSomething = (text: string) => {
    console.log("ok");
};

// function declaration
function doSomething(text: string) {
    console.log("ok");
}
```

What's the other difference? None. Hoisting maybe, but that's another
style thing. Zero perf difference.

</details>

<details>
<summary>Why this change then?</summary>

When I started with JS I thought ES6 was the hottest syntax to write. I
swore by arrow functions everywhere. Then someone said that function
declarations were more readable to people from other languages. This
idea ate at me. I started noticing that my react components are
literally just `const` everywhere. It starts to dilute what the word
even means.

```tsx
const SomeComponent = (props: Props) => {
  const [someState, setSomeState] = useState(false);
  const someVar = 1;

  const onEvent = (event: Event) => {
    console.log('const');
  }; // es6 fans will defend this. the only unique keyword here is return

  return <div>Ok</div>;
};
```

As I lean deeper into programming I like to think readability in code is
one of the most important traits. Separating functions from variables is
a pretty basic step. I'm not sworn off arrow functions (they're great
for anonymous functions), but for everything else, I use standard ol'
`function`:

```tsx
function SomeComponent(props: Props) {
  const [someState, setSomeState] = useState(false);
  const someVar = 1;

  function onEvent(event: Event) {
    console.log('const');
  }

  return <div>Ok</div>;
}

```

</details>

<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->

## Why It's Good For The Game
Code accessibility / easier switch to the hellscape that is javascript
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->

## Changelog

<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->

n/a nothing player facing

<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->

* Function declarations in tgui

---------

Co-authored-by: Jeremiah <[email protected]>

tgui/.eslintrc.yml

@@ -338,7 +338,7 @@ rules:
   ## Require or disallow named function expressions
   # func-names: error
   ## Enforce the consistent use of either function declarations or expressions
-  func-style: [error, expression]
+  # func-style: [error, expression]
   ## Enforce line breaks between arguments of a function call
   # function-call-argument-newline: error
   ## Enforce consistent line breaks inside function parentheses