[PATCH v1] Fix parsing of a complex type that has an array of complex types

Hi hackers,

I ran into an issue today when I was trying to insert a complex types
where one of its attributes is also an array of complex types,

As an example:

CREATE TYPE inventory_item AS
(
    name        text,
    supplier_id integer,
    price       numeric
);
CREATE TYPE item_2d AS (id int, items inventory_item[][]);

CREATE TABLE item_2d_table (id int, item item_2d);

INSERT INTO item_2d_table VALUES(1, '(1,{{("inv a",42,1.99),("inv
b",42,1.99)},{("inv c",42,1.99),("inv d",42,2)}})');

The INSERT statement will fail due to how complex types are parsed, I
have included a patch in this email to support this scenario.

The reason why this fails is because record_in lacks support of
detecting an array string when one of the attributes is of type array.
Due to this, it will stop processing the column value prematurely, which
results in a corrupted value for that particular column.
As a result array_in will receive a malformed string which is bound to
error.

To fix this, record_in can detect columns that are of type array and in
such cases leave the input intact.
array_in will attempt to extract the elements one by one. In case it is
dealing with unquoted elements, the logic needs to slightly change,
since if the element is a record, quotes can be allowed, ex: {{("test
field")}

There are some adjustments that can be made to the patch, for example:
We can detect the number of the dimensions of the array in record_in, do
we want to error out in case the string has more dimensions than MAXDIM
in array.h, (to prevent number over/underflow-ing) or whether we want to
error out if number of dimensions is not the same with the number of
dimensions that the attribute is supposed to have, or both?

Regards,
Arjan Marku