Inconsistent use of set* and add*, especially in FileEntityBuilder

[ThomasJejkal]

As mentioned in #216 there is the need to document purpose and differences of add* and set* in general. While the actual purpose seems to be clear on the semantic level, it's almost impossible to estimate the effect of a set* or add* call without deeper knowledge of the code. Let's take the following example:

FileEntity file = new FileEntity.FileEntityBuilder()
                                .setId("survey-responses-2019.csv")
                                .addProperty("name", "Survey responses")
                                .addType("rdfs:Property")
                                .setLicense(new ContextualEntity.ContextualEntityBuilder().setId("licenseId").addProperty("name", "LicenseName").build())
                                .addProperty("contentSize", "26452")
                                .addProperty("encodingFormat", jsonNode)
                                .setLocation("http://example.com")
                                .build()

• setId - Compared to other calls it should do the same as addProperty('@id', id), but holds id different than other properties, such that addProperty('@id', '123') would not work (and may even cause errors). Furthermore, if the id was already set, the call does nothing, such that overwriting an id is not foreseen (which is somehow fine).
• addProperty - Should be better called setProperty(key, value), as previously added properties with the same name are overwritten. Thus, array values can only be set via addProperty(String, JsonNode). Therefore, one could think of either renaming addProperty to setProperty or changing its behaviour (see next point)
• addType - Actually does what an add-method is supposed to do. At the first call it initializes a HashMap and adds the provided value, while subsequent calls add additional values to the HashMap. So basically the behaviour expected also for addProperty.
• setLicense - One of the most confusing calls. In both cases, it internally calls addIdProperty("license", id). If you call it with a string argument, the value is assumed to be the license id and is directly used. If called with a ContextualEntity argument, getId() is used as license id, while the rest is omitted. Thus, the ContextualEntity of the license has to be added separately to the crate afterwards.
• setLocation - Probably the most confusing call as there are more internal possibilities of what may happen. If called with an URI, the argument is set as id. If id was set before, the call is ignored. If called with a path and the id was not set before, the filename is used as id and path as location. If id was set before, path is only used as location without changing the id. If path is null, nothing is done (unless setLocationWithExceptions is used) and if path points to an non existing file, everything is fine until the crate is written and an exception is thrown.

For the moment, I just wanted to have these points documented for further discussions. I also have the impression, that for other entity builders the situation is much clearer (and mostly limited on the builder-level to set* for single values), but a consistent behaviour would be desirable.

[Pfeil]

I checked the crate builder for something else and found similar issues:

RoCrateBuilder.setLicense(...) is in a way correctly a setter, as it stores and overrides a single license entity that will be used. But the ID will be added in every case. (An entity could even be added twice, which has been fixed in #257, and merged into #256 as the test was related to this.) I could imagine a use to add multiple licenses, so maybe we should provide a addLicense and allow overriding the entity via ID of the license?

In such a case, we need to consider how to fix this without breaking stuff. Do we consider the name setLicense as correct and the implementation a bug, then we could make it empty the list of licenses and add the new one (if we support a list of licenses). But then I'd also deprecate the method and remove it later.

The other way would be to have setLicense act as addLicense and deprecate it also.

The last way would be to only support one license and set the ID instead of adding it. No deprecations needed, but no multiple licenses possible.