fix: properly output and read the filesAnalyzed field in JSON/YAML

[kzantow]

The Package FilesAnalyzed field has somewhat backwards behavior from standard Go JSON -- if it's omitted, the value is true. It had been set as omitempty, which means it was omitted if false (the default for a bool value). This resulted in an impossibility of setting it to false, since it would be omitted from the JSON, which then should be interpreted as true. This PR adjust the behavior so the field is always output, and handles interpreting missing values as true.

Fixes #209

[lumjjb]

the weird part of filesAnalyzed is that if it is omitted technically the correct value is "true" but really no one does it this way... which is kind of cringe, because the intention is usually filesAnalyzed=false... if we actually did a validation check when reading, likely >90% of SPDX documents will fail since they assume omission is default false based on the programming language defaults, and thus they don't include VerificationCode which technically is required if filesAnalyzed=true.

I see trade offs both ways, but since we do require user to signify their intention and the use of the library is not asking users to provide a mandatory field, a golang user will think that it defaults to false. My thought is to perhaps maybe flip the IsFilesAnalyzedTagPresent to IsFilesAnalyzedTagOmitted, or make the default value to true... i don't quite want to break the interface. This may create a experience a bit more aligned with golang

This however, doesn't fix the issue of all the input SBOMs having their filesAnalyzed intent misinterpreted, which technically isn't an issue for the library... but i think it will break enough of the ecosystem that we have to consider it.

[lumjjb]

i thought about it a bit more... maybe what we can do is that during reading, is that if we see no VerificationCode we can set filesAnalyzed=false.. wdyt @kzantow ?

[lumjjb]

the more i look into this, the worse it gets... since filesAnalyzed=false is also an indication that a package doesn't contain any files, this messes things up..

I think my new thoughts around this is to just output it IsFilesAnalyzedTagPresent=true, and otherwise omit it and not assert anything about its intended value but to parse it as is.. We think we will need to support this bad behavior as accounting for a deficiency of the spec.

[goneall]

Just FYI - I check the Java tools to see if it handles fileAnalyzed verification correctly and I believe it does.

If you call the verify() method, it will report a missing PackageVerificationCode if it is not present and filesAnalyzed is also not present.

Note that this will not cause any parsing error - it only reports the issue in the verify() method.

Note - there was an issue in the Java library which may have masked the verification failures for some deeply nested dependencies - this has been fixed in the latest release.

[kzantow]

After discussion with @lumjjb we've decided to merge this PR and look at removing IsFilesAnalyzedTagPresent from the data model at some point in the not-too-distant future.