Add non-docstring alternative for prompts

[Quexington]

Not sure if there's any appetite for this but I figured after diving into it I might as well float it out there.

This PR adds a way to define a prompt that does not exclude the possibility of adding a docstring. It seems reasonable enough to assume that users of the library might want to provide docstrings for their arguments to the prompt that is not itself a part of the prompt.

@outlines.prompt
def my_complicated_prompt(complicated_argument: str):
  """
  This is a prompt that utilized this cool technique you can read about here:
  https://some.website
  
  Parameters
  ----------
  complicated_argument : 
      this argument will help the model to do x, y, z and should fit within these parameters
      for maximum effectiveness
  """
  
  _ = "The actual prompt is here: {{complicated_argument}}"

In addition, making special use of a dunder attribute seems like it could be good to avoid (granted that the suggested parsing of bytecode doesn't seem much more agreeable).

I considered another name for the variable like TEMPLATE but was stopped in my tracks by flake8 who understandably gave me an F841 unused variable warning. Obviously not something you'd want to pass down to library consumers so _ it is.

Worth noting this doesn't actually fix automatic doc generation like with pydoc because that looks at the after-the-prompt-wrapper instance of the Prompt class and gives less than helpful information. Actually, after using functools.update_wrapper, the docstring actually can be made to be helpful for these tools.

[rlouf]

This has been bothering me for a while too, thank you for contributing! I think we might as well return the template. This would allow string manipulations within the function as well.

[rlouf]

This has been bothering me for a while too, thank you for contributing! I think we might as well return the template. This would allow string manipulations within the function as well.

Wdyt @Quexington ?

[Quexington]

This has been bothering me for a while too, thank you for contributing! I think we might as well return the template. This would allow string manipulations within the function as well.

Wdyt @Quexington ?

Sorry for the delay. I'm not sure that returning would work, especially if you try to do manipulation beforehand. I flirted with the idea a bit when I was still trying to use inspect but it wasn't easy/possible to get the actual value being returned that way so you'd have to do the bytecode approach again which gets really complicated if you start adding more instructions to the function.

In addition, the way the scheme is currently designed, this function definition isn't really intended to be run which is somewhat obvious as the current paradigmatic way to do it is to define an empty function with a docstring only. Adding instructions to run would require an edit to the wrapper and would open the door to side effects which are not currently possible.