add TryGetableArray to DeriveValueType macros

[sinder38]

PR Info

• Closes DeriveEntityModel types don't implement TryGetable trait when wrapped in a Vec #2967
  User wrapped types created by DeriveValueType macros don't implement TryGetableArray which results in them unusable in FromQueryResult structs when in Vec<T>

Bug Fixes

• Allow User wrapped types to be used in Vec inside FromQueryResult structs

Breaking Changes

if users implemented TryGetableArray manually it will require removal

Changes

Adds missing implementation to macros

[sinder38]

umm, why is this even allowed?
this is quite confusing.

sea-orm/tests/common/features/value_type.rs

Lines 72 to 73 in e36eea4

	#[derive(Clone, Debug, PartialEq, Eq, DeriveValueType)]
	pub struct StringVec(pub Vec<String>);

error[E0277]: the trait bound `Vec<Vec<std::string::String>>: TryGetable` is not satisfied
  --> tests/common/features/value_type.rs:72:39
   |
72 | #[derive(Clone, Debug, PartialEq, Eq, DeriveValueType)]
   |                                       ^^^^^^^^^^^^^^^ the trait `TryGetable` is not implemented for `Vec<Vec<std::string::String>>`
   |
   = help: the following other types implement trait `TryGetable`:
             Vec<Braced>
             Vec<Hyphenated>
             Vec<JsonValue>
             Vec<NaiveDate>
             Vec<NaiveDateTime>
             Vec<NaiveTime>
             Vec<OffsetDateTime>
             Vec<PrimitiveDateTime>
           and 21 others
   = note: this error originates in the derive macro `DeriveValueType` (in Nightly builds, run with -Z macro-backtrace for more info)

There seems to be 2 ways to solve this:

1. To add more implementations that would cover all cases
   Also I should mention that PostgreSQL supports up to 6 dimensions of arrays, even though I dought anyone nests more than 3

2. It is possible to handle this by not implementing TryGetableArray for types that have Vec inside of them but I think it is bad and confusing. Probably the best way for this option would be to allow user to mark Vec types with something like #[sea_orm(as_pg_array)].

[sinder38]

why not ready

This is not ready to be merged, I handled only DeriveValueTypeStruct and didn't change DeriveValueTypeString.

My reasoning behind it is that I don't fully understand the design goal yet, it could be either:

• "interpret strings in the dB as this complex type"
• "use this convenient wrapper to handle underlying dB type as string".

most likely the first one.