Fix "undefined method `[]' for #<Nori::StringIOFile>" when adding File

[cgunther]

When calling File#add, the response XML sets a type="file" attribute
on the baseRef element, where "file" corresponds to the NetSuite
record. This then causes Nori (the XML parser used by Savon, the SOAP
client) to interpret that element as representing a base64 encoded file,
so it tries to get fancy about how it parses that element into a hash by
returning an instance of it's StringIOFile class:
https://github.com/savonrb/nori/blob/f59f8e18b0e53285c87d75a635058745e66b0bfb/lib/nori/xml_utility_node.rb#L131-L136

Either NetSuite's doing something non-standard with it's use of the
type attribute that Nori is trying to enforce, or Nori is
over-aggressive in trying to typecast to aid the developer.

The end result was that when we tried to extract the internal_id from
the response, the body was actually an instance of StringIOFile, not
a hash:

netsuite/lib/netsuite/actions/add.rb

Line 80 in f0e46a0

@internal_id = response.body[:@internal_id]

To work around this, as I don't see a way to disable such behavior in
Savon/Nori, if we detect the baseRef element was parsed to
StringIOFile, we'll then take the raw XML and parse out the baseRef
ourselves, returning a hash with the internal_id as we'd exect from
non-File responses.

I'm not thrilled with this solution. If we ever needed something else
from the baseRef element, this effectively drops all other attributes
for file records. It also introduces explicit references to Nori and
Nokogiri, both of which are dependencies of Savon, but I'm not sure if
that means this gem should list them as explicit dependencies to guard
against Savon replacing them in a future update. Listing them as
dependencies would then require keeping their version constraints in
sync with Savon most likely.

I believe this answers a question from #481:
#481 (comment)

However the fix in #481 solves it by not trying to extract the
internal_id, which would create a problem if someone wanted to add a
file then save the ID in their own database for future use.

[iloveitaly]

Either NetSuite's doing something non-standard with it's use of the
type attribute that Nori is trying to enforce

My guess is NetSuite is doing something non-standard. I've seen this in other places (the wsdl url).

I'm not thrilled with this solution. If we ever needed something else
from the baseRef element

Thanks for explaning this tradeoff. I think it's a good approach given the situation.

It also introduces explicit references to Nori and
Nokogiri, both of which are dependencies of Savon, but I'm not sure if
that means this gem should list them as explicit dependencies to guard
against Savon replacing them in a future update.

Given that nori is part of the savon GH org, and nokogiri is a very core part of the ruby XML parsing ecosystem, I think it's safe to not include these an optional dependencies for now. I think there is a very small risk that this breaks us in the future.