`Encodable`s should include optional prompt prefixes

[eb8680]

In #456 and #481 we're extending the prompt in synthesis tasks with generic instructions about code generation. Since synthesis is specified in the Template's return type, these types of instructions should probably live on the Encodable type for Callable rather than in a separate handler.

[kiranandcode]

A couple of questions:

• Should encodable prompt prefixes compose? tuple[A, B].prefix = A.prefix + B.prefix?
• Is this really the right place to put prompt prefixes? one concern is that encodable is now becoming a generic catch-all of features. What is the functionality that Encodable is meant to capture, and based on that, why should prompt prefixes be included in it?

A simple solution is to have prefix be a method of encodable, I can make a PR to do that, but I think it might be worth thinking a bit about the interface.

[eb8680]

Should encodable prompt prefixes compose?

I'd expect the prompt prefix in an Encodable to be included only when it matches the return type of a Template, and there's only one return type per Template so I'm not sure how this would ever come up. Maybe if a Template had a Union as a return type?

Is this really the right place to put prompt prefixes?

It's obviously not the right place for all prompt prefixes. But if there's content that should be included any time you want to decode a specific type, regardless of the arguments or context, having it live in Encodable seems like a logical choice.