### Description
When running `ft.info` command the results aren't parsed corr…ectly. If you look into `"numDocs":["bytes_collected",0]` in the parsed response, something went wrong
Example of command result:
```
1) index_name
2) "org-63daa72dfa5bebc3b6ffdccd-app-63f04a80d9aeb523717b0acd-index-644acc8f8a60a87f6e00f4b4"
3) index_definition
4) 1) key_type
2) HASH
3) prefixes
4) 1) index:644acc8f8a60a87f6e00f4b4
5) default_score
6) "1"
5) attributes
6) 1) 1) identifier
2) v
3) attribute
4) v
5) type
6) VECTOR
2) 1) identifier
2) id
3) attribute
4) id
5) type
6) TEXT
7) WEIGHT
8) "1"
3) 1) identifier
2) org
3) attribute
4) org
5) type
6) TEXT
7) WEIGHT
8) "1"
4) 1) identifier
2) createdAt
3) attribute
4) createdAt
5) type
6) NUMERIC
7) index_options
8) (empty array)
9) gc_stats
10) 1) bytes_collected
2) (integer) 0
11) cursor_stats
12) 1) global_idle
2) (integer) 0
3) global_total
4) (integer) 0
5) index_capacity
6) (integer) 128
7) index_total
8) (integer) 0
13) dialect_stats
14) 1) dialect_1
2) (integer) 0
3) dialect_2
4) (integer) 1
5) dialect_3
6) (integer) 0
15) num_docs
16) (integer) 31
17) max_doc_id
18) (integer) 31
19) num_terms
20) (integer) 37
21) num_records
22) (integer) 98
23) inverted_sz_mb
24) "0.00035858154296875"
25) total_inverted_index_blocks
26) (integer) 629596
27) vector_index_sz_mb
28) "6.2732696533203125"
29) offset_vectors_sz_mb
30) "5.245208740234375e-05"
31) doc_table_size_mb
32) "0.0036363601684570312"
33) sortable_values_size_mb
34) "0"
35) key_table_size_mb
36) "0.0013275146484375"
37) records_per_doc_avg
38) "3.1612904071807861"
39) bytes_per_record_avg
40) "3.8367347717285156"
41) offsets_per_term_avg
42) "0.56122446060180664"
43) offset_bits_per_record_avg
44) "8"
45) indexing
46) (integer) 0
47) percent_indexed
48) "1"
49) hash_indexing_failures
50) (integer) 1
51) number_of_uses
52) (integer) 32
```
Example from `node` client:
```
{"indexName":"org-63daa72dfa5bebc3b6ffdccd-app-63f04a80d9aeb523717b0acd-index-644acc8f8a60a87f6e00f4b4","indexOptions":["key_type","HASH","prefixes",["index:644acc8f8a60a87f6e00f4b4"],"default_score","1"],"indexDefinition":{"identifier,v,attribute,v,type,VECTOR":["identifier","id","attribute","id","type","TEXT","WEIGHT","1"],"identifier,org,attribute,org,type,TEXT,WEIGHT,1":["identifier","createdAt","attribute","createdAt","type","NUMERIC"]},"attributes":[],"numDocs":["bytes_collected",0],"maxDocId":["global_idle",0,"global_total",0,"index_capacity",128,"index_total",0],"numTerms":["dialect_1",0,"dialect_2",1,"dialect_3",0],"numRecords":31,"invertedSzMb":31,"vectorIndexSzMb":37,"totalInvertedIndexBlocks":98,"offsetVectorsSzMb":"0.00035858154296875","docTableSizeMb":629596,"sortableValuesSizeMb":"6.2732696533203125","keyTableSizeMb":"5.245208740234375e-05","recordsPerDocAvg":"0.0036363601684570312","bytesPerRecordAvg":"0","offsetsPerTermAvg":"0.0013275146484375","offsetBitsPerRecordAvg":"3.1612904071807861","hashIndexingFailures":"3.8367347717285156","indexing":"0.56122446060180664","percentIndexed":"8","gcStats":{},"cursorStats":{},"stopWords":1}
```
**Comparing this response to a another it seems like the order of the keys is different. Not sure if this would count as a bug for the library or the server. -- notice `index_options` in another response (a local server) is in different place**
```
1) index_name
2) org-63daa72dfa5bebc3b6ffdccd-app-63f04a80d9aeb523717b0acd-index-644acc8f8a60a87f6e00f4b4
3) index_options
4) (empty array)
5) index_definition
6) 1) key_type
2) HASH
3) prefixes
4) 1) index:644acc8f8a60a87f6e00f4b4
5) default_score
6) "1"
...
```
### Node.js Version
18
### Redis Server Version
6.2.10
### Node Redis Version
4.6.4
### Platform
Linux
### Logs
_No response_