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

1.7 Tree based rare+ gen

Changes how rare+ enemies are generated to be based off trees instead of scattered talents. This serves two main purposes:  
1. Fix an issue where the third and fourth talents in trees are extremely rarely taken (by rough simulations by Shibari, about 3% of the time for 3rd and 2% for 4th in High Peak).  
2. Make randbosses feel slightly more coherent and easier to evaluate at a glance.  

The tree system works by assigning major and minor trees, with major trees seeing randbosses taking 3 to 4 talents and minor  trees only 1 to 2 with reduced point investment. Biasing based on whether a tree starts locked or unlocked for a class and by whether a tree is generic or class is currently not implemented, but could be desirable. (Previous randboss generation did not bias by these factors either.)  

Current tuning for balance is based around randboss level and is as follows:  
* Rares:  
  * Major trees: first between 8-10, second between 25-35, third between 50-70  
  * Minor trees: two by base, third around 12-30, fourth around 40-80  
* Unique randboss:  
  * Major trees:  one by base, second around 20-40, third around 50-90  
  * Minor trees:  one by base, second around 11-14, third around 30-60, fourth rarely around 70-90  
* Boss randboss:  
  * Major trees:  one by base, second around 11-23, third around 35-75, fourth rarely around 80-90  
  * Minor trees:  one by base, second around 12-20, third around 40-80  

Note that the amount of trees of each type is slightly randomized, thus why level ranges are provided. Lines 2171-2181 contain the exact functions for numbers of each type of tree at each level if specifics are desired.

See merge request !634

Talent tuning

Tuning of various talents that are excessively powerful on NPCs.  
This accompanies !634, which causes tier 3 and 4 talents to show on NPCs with regularity. 

See merge request !635

otowakotori 1.7 misc fixes



See merge request !630