Metadata validation result should be more specific about the issue

Currently MetadataService validates the metadata against both metainfo.yml and infodict.yml. The former is supposed to be the schema of .torrent files, and the latter -- of the info dictionary (which is also the format of peer-exchanged metadata per BEP-9 Extension for Peers to Send Metadata Files). The reason for this is that IMetadataService interface is generic, so there's no way to know inside of the implementation, which of the two formats the actual metadata has.

I noticed that literally a few lines later we already work around this issue, in order to know which variant of TorrentSource to create, by checking for presence of info property (see comment on this below*). We might move the validations into the IF clause:

BEMap metadata = parser.readMap();
Map<String, BEObject<?>> root = metadata.getValue();
BEMap infoDictionary;
TorrentSource source;

if (root.containsKey(INFOMAP_KEY)) {
	// standard BEP-3 format
	ValidationResult validationResult = torrentModel.validate(metadata);
	if (!validationResult.isSuccess()) {
	    throw new BtException("Validation failed for torrent metainfo: "
			+ Arrays.toString(validationResult.getMessages().toArray());
	}
	infoDictionary = (BEMap) root.get(INFOMAP_KEY);
	source = new TorrentSource() {...};
} else {
	// BEP-9 exchanged metadata (just the info dictionary)
	ValidationResult validationResult = infodictModel.validate(metadata);
	if (!validationResult.isSuccess()) {
	    throw new BtException("Validation failed for info dictionary: "
			+ Arrays.toString(validationResult.getMessages().toArray());
	}
	infoDictionary = metadata;
	source = new TorrentSource() {...};
}

By doing so we will make sure that the user does not see irrelevant validation errors.

--

* This is not a very good approach, because if the info dictionary contained an info property, it would result in a confusion. OTOH, this will not happen as long as the info dictionary strictly adheres to the format outlined in BEP-3.