Integrate value & selector parsing into PostCSS core. #754

So, one of my main concerns about writing cssnano version 4 is that I am trying to glue together lots of different parsers, each with different APIs, and I find myself wanting a much richer AST than what PostCSS currently provides. I feel that as per @thejameskyle's suggestion, we should look at parsing selectors and values;

I'm not sure if PostCSS wants to dive into creating an AST for all CSS values, as that adds a ton of complexity to what is currently extremely simple. Although, most modern compiler authors would [think that] this is the most sustainable solution.

https://github.com/thejameskyle/postcss-function-resolution

This means that we need to extend Declaration and Rule to provide a more detailed AST. I don't exactly know how this should look yet, so any suggestions are welcome. But James' rough draft looks good;

{
  type: Declaration,
  value: {
    type: Expression,
    expression: {
      type: CallExpression,
      callee: {
        type: Identifier,
        name: 'foo'
      },
      arguments: [{
        type: CallExpression,
        callee:{
          type: Identifier,
          name: 'bar'
        },
        arguments: [{
          ...
        }]
      }]
    }
  }
}

Furthermore, I'd like to drop node.raws.value.value and node.raws.value.raw from the AST completely and force plugin authors to provide support for comments or not in their plugins; the current behaviour is that PostCSS will hide comments automatically, which can cause problems with things like userstyles. This would be much easier when we have a unified AST that covers values and selectors as plugin authors can just ignore comments, and instead operate on relevant values.

I am concerned that this is a big change and is not something that I will consider lightly, so I'm looking for feedback. It makes writing complex plugins like cssnano & stylelint easier at the expense of smaller plugins, but I feel like this allows us to do some really sophisticated transforms/analysis in the future.

This issue supercedes #410, #235 & #178.