Parsing Error messages refactor

[johnny-keker]

This PR provides some code refactor for Error messages parsing logic.

Notable change: we do not handle error formats in which location are mentioned after error text.

[timlathy]

Good news: with the latest changes to our tooling, messages like *W,code: text (C:\Absolute\Path\source.c:3, C:\Absolute\Path\source.c:5, C:\Absolute\Path\include.h:10) will no longer be generated, so there's no need to handle this format.

I would suggest keeping most of the changes in this PR with the exception of the code that handles locations after error text (it can be safely removed). I would also prefer to go back to the previous signature of Parse... methods (have them return Message or null). I think it's a good style to keep functions pure by avoiding in-out parameters where it's possible.

[johnny-keker]

Good news: with the latest changes to our tooling, messages like *W,code: text (C:\Absolute\Path\source.c:3, C:\Absolute\Path\source.c:5, C:\Absolute\Path\include.h:10) will no longer be generated, so there's no need to handle this format.

I would suggest keeping most of the changes in this PR with the exception of the code that handles locations after error text (it can be safely removed). I would also prefer to go back to the previous signature of Parse... methods (have them return Message or null). I think it's a good style to keep functions pure by avoiding in-out parameters where it's possible.

Thanks! Is 9fd8cb2 works for you?