Add runtime attribute for locked resources and allow multiple locks

[bgalamb]

Added runtime attribute support for functionality #302

• Added attribute to resource Object

• Changed logic to return resource if it contains the needed attribute even if it's locked

• Changed build reference of Resource to list type List<Run> from Run

• Changed locked by externalID of resource to List from String

• Adjusted methods to work with lists

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!

• Ensure that the pull request title represents the desired changelog entry

• Please describe what you did

• Link to relevant issues in GitHub or Jira

• Link to relevant pull requests, esp. upstream and downstream changes

• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[jimklimov]

This seems to address a similar problem space as #299 (and #20 before it) - but for a somewhat different (or just more specific?) use-case that looks closer to agent/SUT deployment details than lockable resources generally.

Sanity-check: can this goal be implemented on top of that mechanism, to avoid adding vaguely similar fields? Or is it truly different enough?

[bgalamb]

@jimklimov . I think this PR tries to solve a different problem... The linked PR's - #299 (and #20 - add "static" attributes to the lockable resources that you can retrieve into env vars inside the lock block, to get specific and unchangeable values that belong to the given resource.

But this PR is about adding "dynamic" attributes to the resource that live until the/any lock is present.
Normally if a lock is present on a resource then all others jobs would need to wait until it's released even if they require basically the same.

So with this change multiple jobs could lock the same resource (if label and attributes are matching) and can run in parallel.
(I described the use case in #302)