Update to v1.5, add comp_thingsectorlight

[elf-alchemist]

Alongside the fake heights transfer (242), Boom also introduced two separate line specials that individually transfer floor and ceiling light levels (213 and 261) onto a tagged sector. Normally, in Boom and CL9, any Things present in said sector will be lit according to the sector's normal light level. MBF, however, changed this behavior to decide a Thing's light level using the average of the transferred floor and ceiling light levels, instead.

Not only is the MBF behavior incredibly unpopular among mappers, the choice of which behavior is also widely inconsistent among ports. Some ports will only use the Boom behavior of defining a Thing's light level based on the true sector, some will only use the MBF behavior and others will only read the transferred floor light level, instead. This proposition formally defines the behavior in question as part of MBF21.

[elf-alchemist]

Relevant:
doom-cross-port-collab/issue-tracker#1
fabiangreffrath/woof#2393
kraflab/dsda-doom#820
team-eternity/eternity#740
odamex/odamex#1499

[electricbrass]

3 things:

1. There's a copy paste error in the developer spec. The new line still references comp_reservedlineflag.
2. Typo in options.md: trasnfered
3. While in a future standard it would definitely be desirable to have this default to 0, wouldn't it make more sense to default to 1 for MBF21? As that would be the behavior that the majority of existing MBF21 maps would have been tested with.

[thecnoNSMB]

noticed a couple more typos: "preditably" (in README.md), "transfered", "sprties" (both in developer_spec.md), and the documentation for the new setting says "When on" twice instead of "When on/When off".

[elf-alchemist]

Addressed the typographical issues above.

3. While in a future standard it would definitely be desirable to have this default to 0, wouldn't it make more sense to default to 1 for MBF21? As that would be the behavior that the majority of existing MBF21 maps would have been tested with.

As it were, the combination of this behavior being undesired by mappers, and being inconsistent across ports, gives the opportunity to formalize everyone to match the mapper-desired behavior. As my talks with some mappers have shown it's highly unlikely that this will cause some notable regression, and even if it were to do so, being a visual-only change won't cause major issues.