Added lookup functions for multiple files

[tusharad]

• Implemented lookupAllInputs to retrieve all textual inputs with a specific name attribute.
• Implemented lookupAllFiles to retrieve all file inputs with a specific name attribute.
• Implemented lookupInputAs to find a textual input and parse it into a desired type using FromText.
• Implemented lookupAllInputsAs to find multiple textual inputs and parse them into a list of a specified type.
• Added a FromText type class to facilitate parsing of various data types from Text.
• Implemented instances for basic types like Text, Int, Bool, Double, Integer, Float, and Maybe a

Let me know if anything else is required. @maksbotan

[ysangkok]

It seems like the doctest syntax is invalid. Which doctest implementation did you use?

[tusharad]

It seems like the doctest syntax is invalid. Which doctest implementation did you use?

I have converted all the examples to standard Haddock @ ... @ code blocks to match the rest of servant-multipart.

[ysangkok]

Thanks. Is this intended to work with enctype='multipart/form-data' in HTML? Because it seems it would be unintuitive: A checked checkbox would be on (see MDN), which is not accepted as an encoding of True. And an unchecked checkbox would be absent, which is not supported by e.g. lookupInputAs @(Maybe ()), since the key must present. How are you imagining the use case? I am worried that the many ways one can encode data into multi-part forms means that there is no canonical single best way that can fit all writers. Somebody might prefer True/False, others will prefer on/off, and it will be hard to anticipate possible string encodings.

[tusharad]

Hello @ysangkok

When writing the docstring, I had in mind a checkbox group sharing the same name with explicit value attributes, in which case lookupAllInputs returning list works as intended. I have clarified that in the docs.

You're right about standalone checkboxes "on" and absent keys are not suited for lookupInputAs.

If you feel lookupInputAs and lookupAllInputsAs introduce too many assumptions or edge cases , I am very happy to drop both and keep this PR strictly focused on the raw lookupAllInputs and lookupAllFiles functions.

Let me know what you think!

[ysangkok]

I think it's fine to keep them. But could you add comments saying which functions take linear time. Because people could assume that functions named lookup would take constant time.

[fpringle]

Following #80, I suppose these new functions (and their tests) will have to be moved to servant-multipart-api.

[tusharad]

@fpringle I've moved lookup functions to api.

[fpringle]

Looks good!