Add support for byte translation

[MOmarMiraj]

This PR adds support for translating Vec<u8> to the appropriate byte translation for Go, Python, and Typescript.

To maintain backwards compatibility, decided to opt against adding a Bytes in SpecialRustType as there could be some devs translating Vec<u8> into a non byte translation and will be a breaking change.

There was two options I was considering when implementing this feature:

1. Adding it as a decorator so the user could do something like this:

#[typeshare]
#[serde(rename_all = "camelCase")]
pub struct Foo {
    #[typeshare(go,python,typescript(binary_data))]
    pub bytes: Vec<u8>,
}

This option would allow us to use the existing decorators functionality to parse each specific field to determine whether or not we can translate it to its appropriate byte translation.

The issue with this implementation is it would cause a pretty big refactor as the format_special_type function does not have access to decorators and allowing the function to have access whether passing it as an argument or attaching it to each language struct as a field would be overly complex for achieving not the greatest result.

The second option is what this PR does, which is take adavantage of the type_mappings field which allows us to use the typeshare.toml to translate the Vec<u8> to its appropriate translation in each target language. This way is the least complex and is backwards compatible as the user would have to specify inside the typeshare.toml if they want the byte translation otherwise it would keep the current implementation intact.

I added some tests in Go, Python, and Typescript to test this out.

With typescript, as there is no native support for Uint8Array for JSON serialization/deserialization, we have to add these reviver and replacer functions to not lose context of the Uint8Array during serialization/deserialization and the same thing goes for the Python implementation.

[hculea]

This diff is now no longer needed right? It can have the same translation as Array and Slice

[hculea]

This comment is no longer accurate