The neovi interface `use_system_timestamp` feature has compatibility issues

### Describe the bug

I am a beginner with python-can, and am up to learning about the asyncio feature. After I adapted the [asyncio sample code](https://python-can.readthedocs.io/en/stable/asyncio.html) to use the `neovi` interface, I encountered exceptions being thrown in the code which was logging an `asc` file. The code in `asc.py` tries to perform a `split` on the decimal point in [this line](https://github.com/hardbyte/python-can/blob/2e58a21578cf4451538e4e1f45cddbd85d12b488/can/io/asc.py#L406), and this was causing an exception to be thrown due to my timestamps being an integral number of milliseconds. I realized that this was related to the `use_system_timestamp` feature that is specific to the `neovi` interface. It turns out that if this Boolean is set to `True` when creating the `Bus` instance, timestamps from the Bus are emitted as `DWORD` values rather than floats, and the emitted timestamps are in terms of milliseconds rather than seconds.

### To Reproduce

After getting the asyncio example code running successfully as is, change the constructor arguments passed to `can.Bus` ([this line](https://github.com/hardbyte/python-can/blob/2e58a21578cf4451538e4e1f45cddbd85d12b488/examples/asyncio_demo.py#L23)) to instead specify interface of "neovi" and appropriate device serial number, channel, baudrate..., and be sure to include `use_system_timestamp=True` as well. Run up the example to see exceptions being thrown by the ASC logger.

### Expected behavior

I expected no exceptions 😎 . (You can get to the expected behavior by changing `use_system_timestamp=False` or removing that constructor argument altogether.)

### Additional context

OS and version: Windows10
Python version: 3.11.3
python-can version: 4.3.0
python-can interface/s (if applicable): neovi

I think that the goal of the `use_system_timestamp` feature (mentioned [here](https://github.com/hardbyte/python-can/blob/2e58a21578cf4451538e4e1f45cddbd85d12b488/can/interfaces/ics_neovi/neovi_bus.py#L357)) is worthwhile, but I suggest that there should be mention added to the documentation of it being non-standard (by which I mean peculiar to "neovi"), and warnings given regarding the incompatibilities that it can cause with the rest of the python-can ecosystem. I imagine that the trouble which the milliseconds timestamps caused for the ASC logger could be just one of multiple areas where python-can code might get tripped up by the timestamp values being 1000 times larger than "normal" timestamps. Another example might be [this code](https://github.com/hardbyte/python-can/blob/2e58a21578cf4451538e4e1f45cddbd85d12b488/can/message.py#L301) which uses timestamps to determine whether two messages are equal.

Because of the potential usefulness of having it available, maybe there is a different design that could be used to affix OS-compatible timestamps to the incoming/outgoing messages, something universal across all interfaces, and done in a way that doesn't "overload" the traditional timestamping mechanics with new meaning/measurement units? Just a thought...

Traceback and logs

```python
def func():
return "hello, world!"
```