Supplying attributes via yml

[UnsignedByte]

This is specifically related to #466 and #456.

A nice way to store periphery information in the IR/AST is through the use of attributes. With something like port-level attributes, we will have all the necessary tools to store the information used for scheduling. Attributes are a nice way to do this because they are useful outside of scheduling, so we would not need to create special storage for timing tech.

However, we would need to be able to pipe in attributes from external files, such as a .yml (as different targets will have different delays/timing information). This could also allow us to specify attributes at compile time, such as counter_fsm attributes, or even store special information for gen components in attributes rather than the current genconfig setup, so we could maybe replace the #439 setup (which is fairly arbitrary) entirely.

[rachitnigam]

Hmm, seems interesting but potentially puts us on the path of TCL scripts' role in existing flows where tons of program info is stored outside the program. Are there other approaches we can think of where the program or the compiler can reason about this kind of info directly?

[UnsignedByte]

Other than FDO which I think should be an added option to manual specification, not the only option, I can't really think of anything specific at the moment. I will keep looking into it.

[UnsignedByte]

Just realized this introduces even more problems with bundles where the combinational delay of a port in a bundle depends on the index, but I guess for now we could force these to be constant? This will definitely cause issues for automated propagation of combinational delays though.