With some locale configurations (not that uncommon on CentOS), open() may
default to non-UTF8 encodings (eg. ANSI_X3.4-1968).
This is usually not an issue, because we use open() both for writing and
reading. However, AtomicFile implicitly enforces UTF8; which needs to be
mirrored when reading.
Otherwise, normalization is useless, and gives a surprising error message,
such as:
```
<user> config plugins.rss.sortfeeditems oldestfirst
<bot> Error: Valid values include 'asInFeed', 'oldestFirst', 'newestFirst', 'outdatedFirst', and 'updatedFirst', not 'oldestFirst'.
```
This is consistent with what we already do with commands; and generally
makes sense, as we don't want to re-send titles and others when cycling
on UnrealIRCd (which includes a chathistory batch when joining when
chmode +H is set, despite umode +B)
The previous heuristic runs into false positives when imports are merged in __init__.py
More broadly though, it's unlikely automatic 2to3 is particularly useful in 2022 - plugins that were written ~10 years ago are unlikely to work even if syntax errors are fixed.
Spawning one process for each message was a little silly, considering
there can be thousands of messages.
Plus, some instances do reach the timeout after running for a few weeks,
so we really need to fix this.
Ideally, `regexp_wrapper` should also be removed from other plugins
(Todo, Notes, ...) as they have the same issues, but this will do for
now.
.getSpecific() always returned the channel-specific but non-network-specific var,
unless the channel-specific and network-specific one was manually set.
`registry.Value.__call__()` is a wrapper around access to
`registry.Value.value`, that checks if the value was set before the latest
call to `registry.open_registry`; and updates the `value` if needed.
When accessing `registry.Value.value` directly, this cache can't be
invalidated, causing the old value to still be used, until the next call
to `registry.Value.__call__()`.
str() converts them to the exponent notation, which makes split('.')[1]
crash, since there is no decimal part in the exponent notation when there
is a single significant digit.
