pgstat: don't assert on dropped entries when writing stats file

Hi,

I ran into a small pgstat assertion failure while looking at this code
recently.

Here is a simple repro. Set wal_level = logical, then:

Session 1:

```
SELECT * FROM pg_create_logical_replication_slot('slot_a', 'pgoutput');
-- keep the session open
```

Session 2:

```
SELECT pg_drop_replication_slot('slot_a');
SELECT * FROM pg_create_logical_replication_slot('slot_b', 'pgoutput');
SELECT pg_drop_replication_slot('slot_b');
\q
```

Session 1:

```
\q
```

Then restart:

```
pg_ctl -m fast -w restart
```

With assertions enabled, the shutdown checkpoint hits:

```
TRAP: failed Assert("!ps->dropped"), File:
"../src/backend/utils/activity/pgstat.c", Line: 1774, PID: 2117776
postgres: checkpointer (ExceptionalCondition+0xab)[0xbf3f7c]
postgres: checkpointer [0xa46128]
postgres: checkpointer (pgstat_before_server_shutdown+0xcc)[0xa43d89]
postgres: checkpointer (shmem_exit+0xaa)[0x9d8be1]
postgres: checkpointer (proc_exit+0x71)[0x9d89b1]
```

I think the assertion is too strong. Dropped variable-numbered stats entries
can stay in the hash table while references to them still exist. Replication
slot stats make this easy to hit because slot_b can reuse slot_a's slot
index. The stats are serialized by name on disk, but use the slot index as
their key while running.

The old comment made this sound like something that should not happen, or at
least like some cleanup went sideways. But this case can happen without
anything going wrong.

We could probably fix this in the reinitialization path instead, but
that feels like a lot of complexity for a state we can already tolerate.
pgstat_write_statsfile() already skips dropped entries before serializing
them, so the patch just removes the assertion and updates the comment to
match that.

--
Sami Imseih
Amazon Web Services (AWS)