Deduplicate $fish_user_paths automatically

[faho]

In the variable handler, we just go through the entire thing and keep
every element once.

If there's a duplicate, we set it again, which calls the handler
again.

This takes a bit of time, to be paid on each startup. On my system,
with 100 already deduplicated elements, that's about 4ms (compared to
~17ms for adding them to $PATH).

It's also semantically more complicated - now this variable
specifically is deduplicated? Do we just want "unique" variables that
can't have duplicates?

However: This entirely removes the pathological case of appending to
$fish_user_paths in config.fish (which should be an FAQ entry!), and the implementation is quite simple.

TODOs:

• Changes to fish usage are reflected in user documentation/manpages.
• Tests have been added for regressions fixed
• User-visible changes noted in CHANGELOG.rst

[krobelus]

Looks good, this will get rid of the scenario where users add to a universal $fish_user_paths on each startup.
An alternative would be to warn when duplicates were added during startup, but that seems harder to get right.

[faho]

An alternative would be to warn when duplicates were added during startup, but that seems harder to get right.

Yeah, we could warn whenever a duplicate is added, but that's probably too annoying?

Or do naughty things with checking the stacktrace and only warn if it's still in config.fish?

I don't really want this to be something you count on, I'd just like to fix it for the simple case. So I wouldn't even document this, in case we ever decide to remove or replace it.

[IlanCosman]

Doesn't this sort of overlap with fish_add_path? As you said, this problem is worthy of FAQ status, and the answer would be fish_add_path. As long as we advertise fish_add_path in all of the relevant places in the docs, this question should basically go away.

[faho]

Doesn't this sort of overlap with fish_add_path?

Well, yes, obviously. But the point is that, instead of constantly telling people not to do the wrong thing, we can just make the wrong thing not broken.

If you understand universal variables it's obvious that appending to one in config.fish is wrong, but enough people don't understand universal variables (which is also a reason for #7379).

I'm tired of diagnosing "my shell has gotten slow" problems that half the time come down to this (and most of the other half is some plugin that we have no control over).

As long as we advertise fish_add_path in all of the relevant places in the docs, this question should basically go away.

A lot of people don't read the docs. I don't know why, maybe they assumed they don't need to, or they assume the docs are bad.

[ridiculousfish]

This looks good to me too. I think this simple targeted fix is right.

[faho]

Okay, I added some tests, merging.