New hook "Zone:InfiniteDungeon:loadNPCs"

Misc (mostly bugfixes)

The only significant (non-bugfix) change in this MR is to slightly reduce the size of Reknor, which I propose because Reknor is a giant zone immediately on the heels of another giant zone, which leads to a slog.  

Many of the bugfixes included in this merge request are courtesy of minmay, taken with permission from minmay's [bugfix](https://te4.org/games/addons/tome/meteor-fix) addon.

See merge request !637

This reverts commit 306b6a91

Switch chat channel is now unbound by default, as it's not used much and people ended up on different channels by mistake

Updated the way escorts are coded to make them easier to mod. To avoid stuff exploding too much in addons, the old hooks are disabled and now two new ones took their place "EscortRewards:givers" and "EscortRewards:rewards"

Fix rnd_boss_restrict=true will trigger a bug.

Let `rnd_boss_restrict` use `util.getval` interface to make it support defination like `rnd_boss_restrict = true` (in `data/talents/celestial/combat.lua:130`)

Bug report:
```
Lua Error: /mod/class/GameState.lua:2218: attempt to call field 'rnd_boss_restrict' (a boolean value)
```

See merge request !639

Bug report:
Lua Error: /mod/class/GameState.lua:2218: attempt to call field 'rnd_boss_restrict' (a boolean value)

Make using item respect preUseTalent

Currently, using item talent will not check talent's on_pre_use.

For example, Threads of Fate can use See the Threads infinite times on a same map, which is contrary to talent description.

This patch will make it check `actor:preUseTalent`, with `force_talent_ignore_ressources=1`

The HotkeysIconsDisplay is also modified to check preUseTalent.

This would need some tests to see if it would break any item talents.

See merge request !629

Reknor is a huge area immediately following another huge area and isn't paricularly interesting, leading to a bit of a slog (not in a good way) to make it to the east

Fix marauder, archer, and skirmisher not being taught poisons when siding with assassin lord for the first time to unlock the category on an account

Rewrite functions for scaling with diminishing returns approaching a limit

**Why change anything**: current limit scaling functions have an issue where they are very frontloaded and give scaling curves where the vast majority of scaling is done within the first few talent levels. The combatTalentLimit (cTL) function is particularly egregious for this, and it is to the point that @Shibari, @razakai and myself all do not use it and rather use math.min or math.max(combatTalentScale) for better scaling curves. This tends to be an issue most often when the limit is close to the value desired at talent level 5, which is a common use case for cTL of talent cooldowns, talent range, debuff duration, etc.  


**Happy happy math fun time**: the formula I wrote for cTL uses a general calculation of limit*(1-exp[a*√(x)+b]) as opposed to the current formula using a general calculation of limit*(x + a)/(x + b), where for both functions a, b are determined based on the parameters giving for scaling. Both of these are sigmoid functions, i.e. are bounded by a limit and will monotonically either increase or decrease as desired at a slowing rate. The primary desired aspect of the replacement function I suggest is that it will exhibit less drastic increases within the first few talent levels and show more growth from moderate talent levels.   
Similar exponential decay functions are proposed to replace combatStatLimit and combatLimit for consistency; however, these functions do not have as much issue as cTL. As such, I used x^0.75 rather than √x which will provide more similar results to existing combatLimit and combatStatLimit.

See merge request !636