Fix signature saving at Predict saving

[chenmoneygithub]

resolve #1045

Change summary:

• Add a dump_state/load_state pair to Signature class for better modularization.
• Remove the save_verbose option, as it doesn't make sense to change input fields to output fields at loading time. As we are doing "weights-only" saving, the signatures' architecture should match, i.e., input fields and output fields' number and name. Only changeable attributes should be included with saving.
• Save prefix for every field as requested in Saving/Loading Method for signatures in dspy.Predict #1045.
• Added unit testing.

[okhat]

Sorry if I'm forgetting, but is this PR introducing stateful signatures for the first time?

Whether it's old or new, in general, I think it's very risky/hacky to be able to change the object of the signature in-place. Super dangerous IMO. I guess it's fine inside optimizers because they do a deep copy, including of the signatures? In any case, this PR introducing an explicit load_state for signatures seems tricky to me since its usage may not involve a deep copy.

[chenmoneygithub]

For my education - what part is dangerous? IMO this is only giving user the flexibility to set a signature using saved states, and not affecting existing workflows, or say there shouldn't be any regression.

The original issue was users find that optimizer changes the instruction inside signature, but saving does not capture it so the information gets lost. I don't have the full picture over signature, but I find it's legit to be able to save/load a signature, as it's a component subject to change during optimization.