Glayout NLP

[alibillalhammoud]

This PR introduces NLP to Glayout. Currently the features and syntax are limited, this PR defines the framework needed for NLP.

After some research into this subject, I came up with the following:

• I needed some "machine" representation for Glayout Code. This format can be directly translated to python code. The class that stores this representation is called GlayoutCode.
• GlayoutCode is a relational database
• GlayoutCode is itself a GlayoutAction. GlayoutAction is an abstract base class which represents a single action the user may want to do (e.g. place, route, move, etc.).
• classes which inherit from GlayoutAction must override the get_code method. (enforced: python will not allow you to import the relational.py file if it contains an Action which has not done this)
• I implemented some basic actions like importing, moving, routing, placing, creating cell parameters, and creating working variables

I also built out a basic user interface

• A Session class which reads from a stream (by default stdin and stdout terminal in/outs)
• A run.py file (top level program)
• Sessions can output both code and ".convo" files (which are just text files). I included an example ".convo" in gdsfactory-gen/test_case folder.
• Sessions can load in previous conversations, so users can start building component libraries which are saved as ".convo" rather than ".py" files

To build on this, the most important step is improving the underlying Relational database.

@chetanyagoyal Below is my suggestion for a feature development plan:

1. debug the existing features by building out the test_case folder with many conversations. Most errors will manifest when you input "dump code". There should be a descriptive error message printed for easier debugging.
2. improve the relational database. This is straight forward and has the largest direct impact on how well the system works. Especially work on improving routing, maybe create some sort of predictor which can autocomplete port names. Consider how to use the PortTree class, and the currently enforced strict syntax with Port naming to help achieve this.
3. Develop dynamic conversation loading (e.g. extend the ImportCell action to support loading .convo dynamically). We want users to load and place existing ".convo" layout descriptions at runtime.
4. encourage opensource ".convo" contributions, save under glayout/components. Build a library of circuits.
5. After building the relational database very thoroughly, carefully consider adding new syntax support
6. Once these features are built out very well, consider implementing an additional layer of abstraction, which is an LLM that can read general user input and parse through the existing layout library to fulfill complicated user requests.

[alibillalhammoud]

added a new branch to my fork

[msaligane]

@alibillalhammoud Are you planning to address these comments?