Add ability to attach leading trivia directly to buildable nodes

[fwcd]

Based on #474.

This branch adds the ability to attach leading trivia directly to BuildableNodes as a parameter/attribute (currently this can only be done by passing it as a parameter directly to the build syntax method), thereby addressing the points outlined here. This is particularly convenient in TokensFile, where we can now attach doc comments directly to the nodes:

ExtensionDecl(
  leadingTrivia: .newlines(1) + .docLineComment("/// Namespace for commonly used tokens with default trivia.") + .newlines(1),
  modifiers: [TokenSyntax.public],
  extendedType: "TokenSyntax"
)

rather than having to modify the first token (as done currently):

ExtensionDecl(
  modifiers: [TokenSyntax.public.withLeadingTrivia(.newlines(1) + .docLineComment("/// Namespace for commonly used tokens with default trivia.") + .newlines(1))],
  extendedType: "TokenSyntax"
)

thereby making the DSL more readable and more aligned with the actual generated code.

cc @ahoppen @kimdv

[fwcd]

@swift-ci please test

[kimdv]

I like the API. Clean and easy to understand 👏

Was wondering if it would make sense to add a single test that tests if we combine the leading leadingTrivia with a leading trivia on a modifier etc?
Just to ensure that works and will not break 😁

VariableDecl(
       leadingTrivia: .newlines(1) + .docLineComment("/// The `open` contextual token") + .newlines(1),
       modifiers: [TokenSyntax.static.withLeadingTrivia(.newlines(1) )],
       letOrVarKeyword: .var
     )

[fwcd]

@swift-ci please test

[ahoppen]

Yes, this really improves readability of TokensFile.swift 👍

[kimdv]

Since we are defaulting to ?? [] should we not add it here?

[fwcd]

Yeah, I think that's a good idea. I kept it optional to be consistent with the other build-methods, should those be refactored too?

[fwcd]

I think the SyntaxBuildable protocol (and its related subprotocols) currently require this to be optional, so we'd have to refactor that (which might be a larger change).

[ahoppen]

I would suggest that we keep it as-is for now and could consider refactoring it to be non-optional in a follow-up PR.

[fwcd]

@swift-ci please test