Standardize input behavior with timestamp assignment and identify when event time is not used

## What?

Add the ability to recognize events where the `timestamp` field is using the time the message was received by Graylog and does not reflect the time the event described in the message occurred. Additionally:

- it would be helpful to have an indication in the message view, and log view if possible, that provides a visual cue to customers indicating the `timestamp` value does not reflect the event time. This could be a distinct icon next to the timestamp, a color-coded highlight, or other visual indication.
- it may be helpful to have a dashboard that shows the status of the timestamp operation, by source.

## Why?

This feature can reduce confusion during incident response and post-mortem analysis, helping teams trust their log data more fully.

When conducting an investigation it is often important to build a timeline of events, sometimes across multiple sources/log types.

The standard behavior in Graylog is that the `timestamp` value reflects the time the event occurs but that cannot be the case in all events. In some cases the receipt time is used, such as when the syslog input may not be able to parse the header or there is no timestamp in the header, or when it is just not practical to attempt an extraction with inputs such as the raw HTTP input.

This solution should be adjustable in processing time, allowing the indication to be removed for cases where messages can be parsed by pipeline rules, and the event time can be extracted and applied to the `timestamp` field.

## Your Environment

* Graylog Version:
* OpenSearch Version:
* MongoDB Version:
* Operating System:
* Browser version: