fix for nested ternary expressions

[ManuLinares]

I'm not completely happy about this one, maybe we could find a better/proper fix.

[lmichaudel]

Imo it would work better if all the wrap points belonged to the same group, something like that :

		case "ternary_expr":
			String parent_type = ts::node_parent(node).type();
			String field = node.field_name();
			
			bool is_chained = parent_type == "ternary_expr" && (field == "alternative" || field == "consequence");
			
			usz expr_id = 0;
			
			if (is_chained)
			{
				// Inherit the group_id from the parent's wrap point
				// Should be stored in C3Fmt because there could be another wrap group in-between the parent and us...
				for (int i = (int)self.buf.len() - 1; i >= 0; i--)
				{
					if (self.buf[i].kind == TokenKind.WRAP_POINT || self.buf[i].kind == TokenKind.BEGIN_WRAP_GROUP)
					{
						expr_id = self.buf[i].wrap_point.group_id;
						break;
					}
				}
			}
			
			// If not chained generate a new wrap group
			if (expr_id == 0)
			{
				expr_id = self.begin_wrap_group(2);
			}

			self.process_composite(
				node,
				add_wrap_point_fn: fn (String type, String field, usz id)
			{
				switch (type)
				{
					case ":":
						return { .indent = 1, .group_id = id };
					default:
						return NO_WRAP~;
				}
			}, group_id: expr_id);

For instance, with the test it yields:

fn void foo()
{
        ulong i = int_from_5_chars(r[0], r[1], r[2], r[3], r[4]);
        ch = i == int_from_5_chars('l', 't', 0, 0, 0) ? '<'
                : i == int_from_5_chars('g', 't', 0, 0, 0) ? '>'
                : i == int_from_5_chars('a', 'm', 'p', 0, 0) ? '&'
                : i == int_from_5_chars('a', 'p', 'o', 's', 0) ? '\''
                : i == int_from_5_chars('q', 'u', 'o', 't', 0) ? '"'
                : 0;
}

fn void bar()
{
        ch = i == int_from_5_chars('l', 't', 0, 0, 0) ? '<' : 0;
}

We can always tune were it wraps. We could also handle elvis statements with the same code.

[ManuLinares]

I'm happier with it now, what do you think?

I cleaned up the code a little bit, foreach_r seemed like a better/safer fit