Widen set of permitted identifiers in target properties

[lhstrh]

This PR is in response to issue https://github.com/lf-lang/lingua-franca/issues/1194.

For this fix to be viable, the following things still need to be done:

• [ ] adjust getSyntaxErrorMessage so that a parse errors in the target properties do not get mislabeled as an inappropriate use of keywords; and
• [ ] disable highlighting of keywords in target properties (I'm not sure how to do this; @a-sr do you have a suggestion?).

[lhstrh]

Never mind; the issue appeared to be a missing | somewhere :facepalm:...

[a-sr]

I have never altered the default highlighting, I only added new highlighting but this is a different mechanism (semantic). The Xtext docmumentation for code highlighting describes two types of highlighting: lexical and semantic. Default keyword highlighting is a result of the lexical highlighter. However, this mechanism seems to be context-free, probably for performance reasons. Adjusting the default lexical highlighting to detect the target property context and stop highlighting keywords there might do the trick. But only for Epoch, syntax highlighting in VSC is done independently from Xtext.

[lhstrh]

Hm, I think we should first fix the highlighting. What if we conclude that it cannot be done or is extremely awkward?

[lhstrh]

@jhaye, are you interested in taking a look at the syntax highlighting issue?

[oowekyala]

Maybe we should just allow ID("-" ID)* like before but also add an option to use a string literal? This would circumvent this highlighting issue. The key-value pairs also already look like JSON so I don't think it's surprising

target Rust {
    build-type: Release,
    cargo-features: ["cli"],
    cargo-dependencies: {
        "cpu-time": "1",  # here
    }
};

[cmnrd]

I am not sure what the status of this PR/issue is, but this might become obsolete since we plan to move the target properties out of LF code and into an external toml file managed by a build tool.

[lhstrh]

Maybe we should just allow ID("-" ID)* like before but also add an option to use a string literal? This would circumvent this highlighting issue. The key-value pairs also already look like JSON so I don't think it's surprising

I agree, this might be a better solution. Want to push a fix to this branch?