ygen started out as a library that was solely handling generation of Go code, subsequently it has transitioned into being one that generates three different outputs:

• Directories and types - which is to say that it generates an abstract object that maps to a Go struct or a Protobuf message.
• Go code
• Protobuf code

This means that we have a large multi-purpose package that is becoming complex to maintain. Since the only consumers of the public APIs are within our generator binaries, then we have a bit of scope to be able to shuffle this package around - and this should definitely be done prior to a 1.0 release of ygot.

To this end, I suggest that we restructure this such that we have:

• ygen that performs the base mapping of an input YANG set of files into an abstract representation.
• ygot/gogen - a specific package that generates Go code, this should call ygen public APIs to be able to do all the pre-processing and then have the logic to map that into Go.
• ygot/protogen - a specific package that generates Proto code, similar to ygot/gogen above.

This refactoring should likely be done in a few stages:

• Refactor GenerateGoCode to call something close to GenerateDirectoriesAndLeaves
• Make GenerateDirectoriesAndLeaves language agnostic (see discussion below)
• Refactor GenerateProto3Code to call something close to GenerateDirectoriesAndLeaves
• Move GenerateGoCode to its own package.
• Move GenerateProto3Code to its own package.

This was originally:

* [ ] Mechanical move of Go code generation into `gogen`.
* [ ] Mechanical move of Proto code generation into `protogen`
* [ ] Refactoring the generation of `Directories` to be disconnected from the generation of Go (today, there is a linkage to the Go generation since we do not abstract the state storage interface).
* [ ] Refactoring `ygot/gogen` to use the abstract Directories as input.
* [ ] Refactoring `ygot/protogen` to use the abstract Directories as input.

This is a fairly major restructuring, so we'll likely go through some changes to APIs that are incompatible with each other to start with, so we should be careful about figuring out when to cut the next version of ygot - and make sure that this is an RC for 1.0.