feat: add message parser api to jsonrpc and cffi

[Simon-Laux]

api: cffi add dc_parse_message_text_to_ast_json and dc_msg_get_parsed_text_as_json

api: jsonrpc: add get_parsed_message_text_ast_json and parse_text_to_ast_json

[link2xt]

cargo-deny CI complains about duplicate dependencies, they could be added to exceptions or actually fixed (https://github.com/deltachat/message-parser/issues/41)

[link2xt]

Also you probably want to rebase it on stable and change PR base to stable.

[link2xt]

I rebased this onto stable. Would be nice to have a new release of message parser with nom 7 now. Opened an issue: https://github.com/deltachat/message-parser/issues/48

[hpk42]

hum, this got a bit stale -- also i am wondering if message-parsing is not better intetgrated into other message-gettters instead of requiring a separate call to the parser. (maybe based on a flag when querying). Saves a round-trip.
Also, as far as i understood the PR here is not going to be used by Desktop which needs sync-calls to message-parser-compiled-to-wasm (IIRC) so i suggest to close it and mark it with resurrection, and then find some timing for an agreed approach (between UI and core devs) and then tackle/finish it.

[Simon-Laux]

The idea was to get it into core so our UIs and also delta touch can benefit from it without introducing another library. Though Lothar said https://github.com/deltachat/message-parser/issues/43 would be useful to have so he does not need to implement all elements at once.

[hpk42]

yes, the plan is to integrate message-parser into core, i didn't mean to question that. Rather i suggested it might make sense to enhance MessageObject to already return the parsed tree (if there is anything worth rendering in it, so a pure text with no markup/links/addresses etc. could probably just leave this empty). There would be no new API call then. Note that i don't mean to imply any urgency about this -- was just gardening core PRs randomly and this one stuck out as lingering.