Improve type flexibility when building ScVals from native types

[Shaptic]

This enhanced the nativeToScVal helper, allowing more flexibility in the output types.

Specifically, this lets you:

• build scvU32 and scvI32 types
• build scvSymbols from strings and bytes
• build scvStrings from bytes
• build scvVecs with specific types (i.e. recursive type specification)
• build scvMaps with specific types for both keys and values (via a simple type specification format (e.g. type: { field: [ keyType?, valueType? ] } for each entry in the map)

Related: #637

[sreuland]

this may get to be an uber-method to maintain all type permutations for native types in one method. As of now, should docs explicitly show a matrix of valid native type to opt.types? or callers need to look at code.

just for consideration later, ways to cordon options directly to their native types, like a TypeConverter class with toScVal/fromScVal or functional like passing converter function instead like nativeToScVal(val, converterFn). I think recall seeing in past reviews that baking this type of conversions into generated ScVal from xdr was not reasonable.

[Shaptic]

I agree that there's a risk here of permutation blow-up, BUT I'm hoping that this can stay relatively lightweight. The matrix is sparse, so to speak, in that many types have one or two possibilities at most. So hopefully it doesn't get ugly. (In fact, you could even argue that some of the permutations are the fault of design mistakes on the XDR level, like ScVal.scvStrings taking a Buffer, but I digress...)

With the discussion on custom, user-defined types in #637, you very well may be right that this can end up exploding into an uber method... so let's cross that bridge if we get to it? I don't want to over-invest a lot of architectural thought into this until we get community feedback on whether or not this is even a useful abstraction to provide in the first place. I think of this as a "minimum high-level implementation" to try to help downstream folks not deal with XDR so much, more-so than a perfect v0 solution.