fastparse 2 usability issues

[pshirshov]

1. When we try to port code which was completely legit in fastparse 1, like

  def adt[_: P](sep: P[Unit]): P[AlgebraicType] = P(adtMember.rep(min = 1, sep = sep))

we are getting odd compiler warnings like

a pure expression does nothing in statement position; multiline expressions might require enclosing parentheses

and our parsers are failing with insane errors (like cast exceptions or stack overflows).

fastparse 2 requires all the parsers to combine be defined as by-name parameters but not enforces it. So, the following snippet is correct:

  def adt[_: P](sep: P[Unit]): P[AlgebraicType] = P(adtMember.rep(min = 1, sep = sep))

I think that this behaviour should be enforced somehow - it is possible to verify the nature of the value from within a macro.

2. Seems like scaladoc fails on expressions with CharsWhileIn:

  final val digits  = "0123456789"
  final val hexDigits = digits + "abcdefABCDEF"
  def HexNum[_: P]: P[Unit] = P("0x" ~ CharsWhileIn(hexDigits))

[error] /work/idealingua/idealingua-core/src/main/scala/com/github/pshirshov/izumi/idealingua/il/parser/structure/syntax/Basic.scala:16:52: Function can only accept constant singleton type
[error]   def HexNum[_: P]: P[Unit] = P("0x" ~ CharsWhileIn(hexDigits))
[error]                                                    ^

The code compiles fine, just scaladoc dies. I guess scaladoc runs before application of these ref transparency optimizations and it's not actually a fastparse issue, but it's very odd and misleading.

[lihaoyi]

It's a bit hard to generally solve this, but we have some work in progress that might help #204