Changed out path for overridden targets for consistency

[lefou]

To be more consistent with the changes from PR
#1588
which re-layouted the log, meta, and dest path for targets.
This change touches the path of overriden target results.
It replaces the ../target/overriden/.. part with
../target.overriden/...

There is a catch though, to make this work I had to remove one
require assertion, which guarded the presence of dots (.) in
labels. TBH, I previously stubled upon this require
and also added the FIXME comment to it, as it is unclear why it
even exists. Probably, because labels with dots can't be properly
parsed when given on cli. More details and hisory can be found in
issue #820.

Fix #820.

Review by @lihaoyi.

[lihaoyi]

It would take some refactoring to make the path/segment handling "clean", but I'm fine with removing the assert for now

[lihaoyi]

The fundamental issue with that assert is that Segment currently (with that assert) models things which can be parsed from the CLI, whereas the .override things cannot be parsed from the CLI. Thus using Segment to model the foo.override/ paths is not correct.

One slightly-less-hacky thing we could do is to add a third case to Segment, e.g. Segment.Override or something, to explicitly model this. Then we can ensure that the parser only returns Segment.Label or Segment.Cross, but other places we can synthesize Segment.Overrides as well. That would also be a good direction to go in if we in future decided to allow people to build the overridden targets directly from the CLI, which AFAIK is currently not allowed.

There are probably other things we could do, but this was the solution I thought of off the top of my head.

[lihaoyi]

On second thoughts, the .overridden data can only apply once to an entire Segments, and thus should apply to Segments as a whole and not be a replacement for any individual Segment

[lefou]

@lihaoyi Nice thing is, this PR actually fixed #820.

[lefou]

I'd like to keep the mapping to Segment.Label as-is for now. CLI parsing is at some degree unrelated, as the removed require was just an after-the-fact guard and there is still a unique mapping of parsables to segments. The only issue is, that it's not bidirectional, but we don't generate cli arguments from segments, do we? (If we do, e.g. when completing, we could filter them out.) We could come up with some quoting or escaping, if someone really needs that feature, which is rather unlikely.

[lihaoyi]

@lefou we actually do generate a string from the Segments data structure in a few places via Segments#render, e.g. to populate the mill-profile.json.

I don't think we actually need it to be parseable - in the end it's just for debugging purposes - so I'm happy to merge this PR as is and figure out a way to clean things up later