Fill some gaps in generating types for Typescript from the IDL

[eoin-betdex]

Closes #1392

We've run up against two small issues when working in Typescript with the types generated for account fields from the IDLs.

1. Option<T> fields map to unknown type in Typescript when T is one of the standard types defined in TypeMap, e.g.,

#[account]
pub struct MyAccount {
    pub counter: Option<u16>,
}

const accountAddress = "...";
const myAccount = await myProgram.account.myAccount.fetch(accountAddress);
const counterPlusOne = myAccount.counter + 1;  // Assuming the counter has been initialised

Results in TS2365: Operator '+' cannot be applied to types 'unknown' and '1'.

Adding in an additional clause to DecodeType<T extends IdlType, Defined> allows the types declared in TypeMap to be supported as type parameters of Option<T>, and for those types to map correctly into Typescript types.

2. Vec<String> fields map to unknown type in Typescript. Only the types defined in TypeMap are considered when determining how to map a Vec<T> to some T'[].

#[account]
pub struct MyAccount {
    pub my_strings: Vec<String>,
}

const accountAddress = "...";
const myAccount = await myProgram.account.myAccount.fetch(accountAddress);
const myStrings = myAccount.myStrings;

for (const myString of myStrings) { ...

Results in TS2488: Type 'unknown' must have a '[Symbol.iterator]()' method that returns an iterator. Adding in a mapping from string: string in TypeMap corrects this.

Keen for input on whether we can get this fixed and if there are any additional changes we should make or code paths we should investigate; Or to understand if there are other changes to type support in Typescript coming that means we should leave this as it is for now.

Thanks!

[eoin-betdex]

Thanks!