enable logging with milliseconds since boot and system time in rust logs depending on configuration

[mike1703]

This change allows to set one of these configurations

• CONFIG_LOG_TIMESTAMP_SOURCE_RTOS
• CONFIG_LOG_TIMESTAMP_SOURCE_SYSTEM
  source: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/kconfig.html#config-log-timestamp-source

I'm open for suggestions on how to properly structure this as I'm not sure how to do this kind of conditional selection of what to print as the original timestamp is u32 and I wanted to avoid having another nested case distinction inside both color paths.

This allows timestamps like the following if CONFIG_LOG_TIMESTAMP_SOURCE_SYSTEM is set

I (00:00:01.742) main_task: Calling app_main()

[ivmarkov]

My one concern with this PR is that we would start using a logging API - which is - IMO - flawed.
There is a question about the soundness of this API here.

The TL;DR is, esp_log_timestamp returns the data from its own static buffer. While the modification of this buffer is protected by a lock, reading from this buffer is not protected at all.

I also do not understand the counter-arguments of both @igrr and @ESP_Sprite (not really sure what is his GH id to ping him here) where they say that - to paraphrase - "you would still read a properly formatted timestamp, even if the internal buffer is being modified while you are reading".

Folks, while I get it that it is impossible - by just reading the internal buffer of esp_log_timestamp without a lock - to get something like e.g. "25:67:99" for hh:mm:ss (i.e. the timestamp will "look" correct), this does not make the timestamp correct in the first place.

Imagine that the timestamp which is being read right now is "23:59:59" and the reading code read (and printed) only the first digit, i.e. "2" and then the scheduler kicked-in and re-scheduled the task because of - whatever - maybe the UART is full and we need to IO-wait or really whatever.

If - in the meantime - another thread calls esp_log_timestamp, this other thread will change the timestamp to "00:00:00". So once the first thread resumes its work, it would actually print - in the end - "20:00:00" which is as wrong as it gets.

@igrr - What am I missing?