feat: prepare public API for alpha release

[OmarTawfik]

• created a slang_solidity::syntax module, with sub-modules nodes, parser, and visitors.
• renamed codegen_parser to codegen_syntax accourdingly.
• renamed Visitable::visit() to Visitable::accept_visitor().
• made Visitable::accept_visitor_with_path() private, since it accepts a &mut path, and we expect/pop nodes in a certain order that external callers can violate.
• renamed ParserOutput to ParseOutput to match parse().
• changed a few internal helpers/constructors to pub(crate) instead.

Tested using cargo rustdoc.

[AntonyBlakey]

I have some general issues with the semantics of the renamings in this PR.

created a slang_solidity::syntax module, with sub-modules nodes, parsing, and visitors

nodes and visitors are nouns, but parsing is a verb.

renamed codegen_parser to codegen_syntax accourdingly

Note sure about this for the same reason. It does generate the parser. I know we discussed this, but now that I see it, I'm not convinced. I think it makes it less semantically clear.

renamed Visitable::visit() to Receiver::receive() for correctness

IMO Visitable is much more descriptive than Receiver because it ties it to the Visitor. I understand the linguistic relationship of receiving a visitor, but Receiver seems too generic (Sender/Receiver), and the -able suffix is better linguistically for me. The only other alternative that seems right is ReceiveVisitor::receive_visitor, but I strongly prefer -able for the name of this role in these kind of patterns.

renamed ParserOutput to ParseResult to match

I see ...Result and I think Result<T>, with the corresponding type semantics. Which ParserOutput is not.

[OmarTawfik]

created a slang_solidity::syntax module, with sub-modules nodes, parsing, and visitors*

nodes and visitors are nouns, but parsing is a verb.

f2f: let's use nodes, parser, and visitors for now.

renamed codegen_parser to codegen_syntax accourdingly

Note sure about this for the same reason. It does generate the parser. I know we discussed this, but now that I see it, I'm not convinced. I think it makes it less semantically clear.

f2f: let's use codegen_syntax for now.

renamed Visitable::visit() to Receiver::receive() for correctness

IMO Visitable is much more descriptive than Receiver because it ties it to the Visitor. I understand the linguistic relationship of receiving a visitor, but Receiver seems too generic (Sender/Receiver), and the -able suffix is better linguistically for me. The only other alternative that seems right is ReceiveVisitor::receive_visitor, but I strongly prefer -able for the name of this role in these kind of patterns.

f2f: let's use Visitable::accept_visitor()

renamed ParserOutput to ParseResult to match

I see ...Result and I think Result<T>, with the corresponding type semantics. Which ParserOutput is not.

f2f: let's use ParseOutput, as it is returned from a parse() method.

[OmarTawfik]

Should also add rust-lang/cargo#1982 to the dummy module comment.

[OmarTawfik]

Comments addressed, and PR description updated with changes.