speedup report generation by using class attribs instead of instantiating

[leondz]

drop the () after the class accesses in report_digest to skip this slow, inefficient step

docstrings guaranteed to be in place through tests.test_docs.test_check_docstring

[jmartin-tech]

Looks good. This also points out a that during review we need to be aware that class doc first line needs to be an complete sentence.

g.description
'Generator wrapper using LiteLLM to allow access to different'

g.__class__.__doc__.split("\n")[0]
'Generator wrapper using LiteLLM to allow access to different'

[leondz]

Looks good. This also points out a that during review we need to be aware that class doc first line needs to be an complete sentence.

g.description
'Generator wrapper using LiteLLM to allow access to different'

g.__class__.__doc__.split("\n")[0]
'Generator wrapper using LiteLLM to allow access to different'

Good point - split("\n\n") makes better sense

[jmartin-tech]

While that would allow longer descriptions in our reports it would not align with the python docs PEP

Multi-line docstrings consist of a summary line just like a one-line docstring, followed by a blank line, followed by a more elaborate description. The summary line may be used by automatic indexing tools; it is important that it fits on one line and is separated from the rest of the docstring by a blank line. The summary line may be on the same line as the opening quotes or on the next line.

Let's stick with this as is and do a pass at ensuring existing doc strings conform.

[leondz]

I think I'm missing where it doesn't align - I think end line plus blank line is \n\n in our file format

[leondz]

this resolved #719