[fix] Always render parens for capitalized methods with receivers

[reese]

Closes #869

TL;DR for callers where the receiver is a ConstantReadNode (e.g. Foo::Bar() { }), parentheses are required for Prism to parse that call, so this adds a receiver check to ensure they're always left behind in this case.

---

Capitalized methods are a bit of a strange creature when it comes to how the parser handles them. On their own, they're essentially fine: a plane ol' Foo is a constant, and Foo(), Foo { }, Foo do; end or Foo() { } are all CallNodes. In all of those cases, Prism understands them to be calls as soon as it sees the parens or the block delimiters, so we can elide parens if there's nothing in them, as long as a block is present.

However, this isn't the same for capitalized methods where the receiver is a ConstantReadNode. In those cases, once Prism gets through the method name (e.g. Foo::Bar), it's ambiguous as to whether it's a constant or a call. For whatever reason, brace blocks actually do work fine here, and Foo::Bar { } is a totally valid call in Prism (not in parse.y!), but Foo::Bar do; end is not. For these, it's required that capitalized methods in constant reads use parens to force the parser to understand them as method calls, so Foo::Bar() do; end works.

Note: for the sake of consistency, I chose to just check for any receiver and not care about the block type. In theory, we could still elide parens for block braces if we wanted to, but (1) I don't think older parser versions accept that, and (2) if we're required to have parens some of the time for this type of caller, I think it makes sense to just keep them all of the time.

[reese]

I just tested every combination of with/without parens and with/without brace or do/end blocks, but please double-check that all of these are what we expect. I think they're right, but I'd like to make sure these cover every possible case