Fix type issue with ListFilesResponse

[MakotoE]

This is a breaking change!
When using Files::list(), I found that if you have zero files in your account, it returns an error. But it should be able to parse the response in this case and return a result.

I included a test case to demonstrate this behavior. Currently, the test will cause this unwrap error:

called `Result::unwrap()` on an `Err` value: JSONDeserialize(Error("invalid type: null, expected a string", line: 5, column: 18), "{\n  \"object\": \"list\",\n  \"data\": [],\n  \"has_more\": false,\n  \"first_id\": null,\n  \"last_id\": null\n}\n")
thread 'file::tests::test_empty_file_list' panicked at async-openai\src\file.rs:152:54:
called `Result::unwrap()` on an `Err` value: JSONDeserialize(Error("invalid type: null, expected a string", line: 5, column: 18), "{\n  \"object\": \"list\",\n  \"data\": [],\n  \"has_more\": false,\n  \"first_id\": null,\n  \"last_id\": null\n}\n")
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library\std\src\panicking.rs:697
   1: core::panicking::panic_fmt
             at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library\core\src\panicking.rs:75
   2: core::result::unwrap_failed
             at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library\core\src\result.rs:1765
   3: enum2$<core::result::Result<async_openai::types::files::file::ListFilesResponse,enum2$<async_openai::error::OpenAIError> > >::unwrap
             at C:\Users\MakotoEmura\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\result.rs:1167
   4: async_openai::file::tests::test_empty_file_list::async_block$0
             at .\src\file.rs:152
...
  26: async_openai::file::tests::test_empty_file_list
             at .\src\file.rs:152
  27: async_openai::file::tests::test_empty_file_list::closure$0
             at .\src\file.rs:150
  28: core::ops::function::FnOnce::call_once<async_openai::file::tests::test_empty_file_list::closure_env$0,tuple$<> >
             at C:\Users\MakotoEmura\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\ops\function.rs:253
  29: core::ops::function::FnOnce::call_once
             at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library\core\src\ops\function.rs:253
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I changed the first_id field to a Option to mitigate this. However, this is a breaking change, so maybe it is better to use serde's default value for the string in case the field was null.

I recommend changing all pagination id's for other structs the same way as well.

[64bit]

Thank you for the fix and test!

[64bit]

Fixed this in v0.31.1 (did a patch release because the latest release was very recent - so I do not expect high usage of it yet)