Additional attribute block improvements

Approaches / TODOs extracted from discussion below:

- [x] make a proper design of the block that fits our other decisions #75
- [x] make it functional (it probably needs adapt a bit to the given PID like displaying a proper name) #75
- [x] check the generated code is fine #75
- [x] Validation fields for key -> must be constant string and resolvable PID at Design-time
- [x] Validation field for value -> same as in profile
- [ ] In future, we could have a block which resolves the text (in the browser already), shows if it could successfully resolve the type and show its name or so. In principle, already achievable now. We'd need to resolve the PID by calling hdl.handle.net/$PID, then check for a name attribute at the highest level and display it. Otherwise, we show a "failed" icon as we do with validation. The "Additional Attribute" block would accept this block as input.
- [ ] A further step could be a searchable block (searching in a set of available DTRs), but I think this is not a big advantage in the current DTR situation. Alternatively, we could have a curated list of recommendations or so. But I'd postpone this for later when we collected some feedback.

Start with the discussion and completed design and implementation referenced in #75, then inspect the existing Additional Attribute block and its validation behavior. Done would require a decided and implemented approach for browser-side PID resolution, name display, and input-block integration; searchable DTR recommendations are explicitly deferred.

Written by the indexing model from the issue text.