Add ability to defined new parser combinators

The current parser combinators library is flexible but lacks the ability to easily define new combinators.
For example, in a
grammar that supports JavaTokensParser.wholeNumber and JavaTokensParser.floatingPointNumber literals and an e .. e expression,
1..2 is ambiguous; and 1. is parsed as a floating
point literal.

    import scala.util.parsing.combinator.JavaTokenParsers
    object R extends JavaTokenParsers with Application{
      def RANGE = ":"
      def range_expression = value_expression~RANGE~value_expression
      def value_expression = /* other stuff eventually working down to */ literal_expression
      def literal_expression = ( stringLiteral | floatingPointNumber | wholeNumber | ident )
      println(parseAll(range_expression, "1" + RANGE + "n"))
    }

I'm using 2.7.6-final and want to define a new combinator similar to ANTLR's lookahead guard.

   (Integer "..") => Integer // Prevent 1..2 from being tokenized as 1. followed by .2

Obviously, I can't use => in Scala, but I would like to define something like

  a<~~b

which will parse a and b but reset the Input to just after where a was found. In the 2.8 trunk there is a similar guard(Parser) combinator that is used as a<~guard(b) but that is not yet available.

Currently, it is not easy to add new combinators because other parsers/combinators return type Parser which does not see new combinators. I suppose implicits may help, or http://scala.sygneca.com/patterns/pimp-my-library
but something built into the framework would be better, if possible.

Start by inspecting the parser-combinators Parser and existing combinator APIs, then compare them with the 2.8 trunk guard(Parser) combinator mentioned in the issue. Use the JavaTokenParsers range example to evaluate the proposed extension mechanism. Done means users can define new combinators and handle the 1..2 versus floating-point ambiguity without losing parser composition.