Core: fix unfilled items "Per-Player Count"

[Silvris]

What is this fixing or adding?

At some point (likely the region caching rework), multiworld.get_locations was changed to include unfilled locations as well as filled, creating a mismatch between the evaluated per-player count and the actual player location count.

How was this tested?

Debugging two plando bugs, and wondering why the counts were showing an additional 2 locations.

If this makes graphical changes, please attach screenshots.

[Ixrec]

This is my first time looking at fill.py, since qwint asked for more eyes on this in Discord, but I can't make heads or tails of what's going on with this change even with the PR description.

get_locations() if location.item and .get_filled_locations() seem to be doing the same thing, from looking at the (current) implementation of get_filled_locations(), so changing that part seems like a clear readability improvement.

That would imply the real change is the deletion of the .update() below. This appears to only affect the "Per-Player counts" log, but why do we want these counts to include unplaced items while excluding unfilled locations? Since they don't specify, I would've naively expected these counts to be all items and locations, including the unplaced items and unfilled locations.

And the PR description says that get_locations() used to be filled only. But if that's the case, why is there already a if location.item check here? Does "filled" mean something different from "has an item"?

[Silvris]

The unfilled locations are already accounted for within .get_locations(), we don't need to duplicate them. I wasn't actually sure that it used to be filled only, I just assumed that to be the case since it would justify the existence of adding the unfilled. We have to update the items, as since these items remained unplaced, they have no ties to any location.

[qwint]

not certain about the code changes but they seem simple enough
but I did test both main and this branch using my world (minit) to submit too many items and not enough items and see the messaging, which seems to replicate the issue Silvris is trying to solve and show it corrected on the PR's branch
too few items on main (6 too few), the Counters misrepresent unfilled locations

too few items on this pr (6 too few), the Counters match the rest of the info

too many items on main (9 too many), no issue

too many items on this pr (9 too many), no change (so no issue)