cfg_select: Support unbraced expressions

[joshtriplett]

When operating on expressions, cfg_select! can now handle expressions
without braces. (It still requires braces for other things, such as
items.)

Expand the test coverage and documentation accordingly.

---

I'm not sure whether deciding to extend cfg_select! in this way is T-lang or T-libs-api. I've labeled for both, with the request that both teams don't block on each other. :)

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jieyouxu]

Question: do you know why cfg_select! required braces previously? Did this have any grammar ambiguity problems?

[joshtriplett]

When it was not a built-in macro, I think it was needed to handle expressions. Once it became a built-in macro, I think it was just simplicity of implementation.

[jieyouxu]

Interesting. This would probably require #144323 to change again 🤔

[folkertdev]

Changing it is fine, but I don't really see a way here to decide whether to format with the comma or as a block? For match that is based on whether there is a statement (i.e. a ;) in the rhs, here I don't see how we can decide when the , variant is desired, unless the formatter should always use a , in expression position?

Alternatively we just stick with the user's formatting choice, in which case that information needs to be stored.

[joshtriplett]

@folkertdev I think the right answer there would be to determine whether it needs to be wrapped onto a new line, and if it doesn't, and it's an expression, write it without braces and using a ,. That's similar to how match is handled other than the "is an expression" check.

[Amanieu]

We discussed this in the @rust-lang/libs-api meeting and everyone was happy with this change.

[traviscross]

We discussed this in the lang meeting. We were all happy to see this land in nightly. Thanks to @joshtriplett for putting this forward.