Rename `TokenSymbol` to `Symbol`

[onurinanc]

TokenSymbol is currently named as if it were specific to tokens, but the type itself is generic enough to represent any uppercase symbol with this encoding logic. Renaming it to Symbol would make the API more reusable, and avoid implying token specific naming.

As an example, this type could also be used for Role-Based Access Control identifiers, such as Symbol::new("MINTER"), which shows that the Symbol abstraction is applicable beyond TokenSymbol

[PhilippGackstatter]

Overall the use case for encoding different things using the same logic makes sense, but I would keep the TokenSymbol type for type safety and introduce a Role type that represents a role in role-based access control (or whatever is appropriate in that context) and have another type to encapsulate the encoding/decoding logic.

So, I think we can achieve this as follows:

• Move the encoding/decoding logic from TokenSymbol into a more generic type, say, Symbol.
• Keep TokenSymbol, but redefine it as struct TokenSymbol(Symbol) to reuse the encoding/decoding logic.
• Introduce a struct Role(Symbol), or whatever is appropriate for the role-based access code.

That way, we can reuse the main string -> felt conversion logic from Symbol in various place, just like we do this with TokenName that wraps a FixedWidthString and other similar types in #2439. Additionally, we keep type safety, i.e. TokenSymbol remains a type that represents the symbol of a token and cannot be accidentally used where a Role is expected, and vice versa for Role.

[onurinanc]

I think there are two different directions here.

Option 1:

Keep the TokenSymbol as it is, and introduce a separate RoleSymbol.
In this approach, RoleSymbol would be a separate type with its own validation rules, allowing up to 12 characters from A-Z plus underscore character "_" so that we can give specific name such as "MINTER_ADMIN" 

Option 2:

Extract the shared encoding/decoding logic as you specified into a generic Symbol type, and then wrap it in two different types where:

• TokenSymbol(Symbol), where it validates only A-Z
• Role(Symbol), where it validates A-Z plus" _".

My preference would be option 2 since it gives us both reuse and type safety.

[PhilippGackstatter]

Ah, I hadn't realized we want a different alphabet for Role. I guess as long as that doesn't change the number of characters we can encode for the token symbol, we could go with Option 2 and allow A-Z and _ in Symbol, and validate that only A-Z is used in TokenSymbol.