Evaluate if Symbol::new should try to optimize or always create symbol using host fn

[leighmcculloch]

Today the Symbol::new function in the SDK/Env converts a &str to a Symbol by checking if the length of the str is small enough to be encoded as a SymbolVal, and if so it takes that route, otherwise it calls a host function copying the str to the host and getting back a SymbolObject.

The current approach was implemented before we knew much about how costs and fees would work on Soroban, and makes some tradeoffs that may not be the right tradeoffs anymore. We know more today than we did a year or more ago about costs and fees and should re-evaluate if the existing behavior and tradeoffs are appropriate.

Todays approach where Symbol::new optimistically returns a SymbolVal or SymbolObject optimizes for less host function calls, but str to SymbolVal conversion costs ~200 bytes of WASM instructions.

Another approach where Symbol::new always returns a SymbolObject would optimize for smaller contracts and result in only an additional ~58 bytes of WASM instructions but result in an additional host function call for every conversion.

More analysis is required when priorities permits.