fix: reset MessageListener.stopped when re-adding to a notifier

[drewr95]

Summary

can.Notifier.stop() calls listener.stop() on every listener it holds,
which sets MessageListener.stopped = True permanently -- nothing ever
resets it. ElectronicControlUnit creates its listener once in __init__
and reuses it for the ECU's whole lifetime.

The ECU and its Notifier are governed by separate ref-counted registries in
consuming code (e.g. j1939_utilities' EcuRegistry/NotifierRegistry). If
a shared notifier's refcount independently hits zero while the ECU itself
survives (some other consumer still holds an ECU reference), the notifier
gets torn down and a fresh one created -- but add_notifier() was re-adding
the ECU's same, already-stopped=True listener to the new notifier without
clearing the flag, silently and permanently dropping every future frame for
that ECU even though the notifier is alive and the listener is registered
on it.

Fix

Reset listener.stopped = False in add_notifier() before re-adding it to
the (possibly new) notifier.

Context

Found while investigating boom_integration_tests rotary/tilt startup test
flakiness at full-suite scale (downstream consumer, pinned to a commit on
this fork). Turned out not to be the actual root cause there (a stray CAN
bus filter left by an unrelated fixture in a different repo), but this is a
real, independently reproducible bug in its own right -- confirmed present
at the currently-pinned commit.

Testing

No local test env for this repo in my sandbox; happy to add a regression
test if wanted, or if pointed at the right test scaffolding.

[drewr95]

Wrong target repo — recreating against RaulSMS/python-can-j1939, which is the fork this project actually depends on.