Not handling Arrays or Hashes without type name

[connorshea]

Describe the bug
Sord doesn't correctly handle <String> (should be equivalent to Array<String>) or {String => true} (equivalent to Hash{String => true})

I tested sord with zeitwerk and discovered this issue.

To Reproduce

# Absolute paths of files or directories that have to be preloaded.
#
# @private
# @return [<String>]
attr_reader :preloads

Expected behavior

sig { returns(T::Array[String]) }
def preloads(); end

Actual behavior

# sord warn - "<String>" does not appear to be a type
sig { returns(SORD_ERROR_String) }
def preloads(); end

Additional information
The type parser seems to suggest these are valid, so we should try to support them.

[connorshea]

Tested a few gems to see what errors were left to fix:

• addressable - no SORD_ERRORs
• gitlab api gem - no SORD_ERRORs
• zeitwerk - this issue
• yard - solved by Update duck type regex to allow setter duck types. #42
• rspec-core - 2 SORD_ERRORs, most notably this one caused by a linebreak, maybe we can fix this by just filtering out any \ns?
• bundler - 13 SORD_ERRORs where they're pretty much all this issue
• haml - 33 SORD_ERRORs mostly due to this issue or some weird invalid stuff like String or nil
• rouge - 302 SORD_ERRORs, all of which are caused by unsupported generic type "Class" in "Class<Rouge::Lexer>
• aws-sdk-s3 - 12 SORD_ERRORs, all of these just seem to be weird invalid things the gem does.

[AaronC81]

That's a really useful insight into where Sord is now! Rouge's issue can be sorted by translating Class<X> into T.class_of(X); I'll create an issue for that.

[AaronC81]

This should now be implemented - Zeitwerk no longer has any errors related to this!