feat: add support for disabling locking with NoOp lock provider

[duoctranth]

This pull request introduces the ability to disable locking functionality by adding a new action input called disable-locking. When set to true, it utilizes the NoOp lock provider, which performs no actual locking operations.

The logic code has been implemented to support this new feature, ensuring the appropriate environment is utilized based on the disable-locking input value.

For more details, please refer to the linked issue.

Linked Issue: #99

[Spartakovic]

I think this kinda defeats the purpose of having polymorphic lock if we need to do a type check.

[duoctranth]

Thank you for your feedback. Regarding the NoOpLock, would it be possible to add an additional return parameter called lockIgnored to the Lock interface instead of using this alternative approach?
I'm open to exploring other ideas as well. Please let me know if you have any suggestions or recommendations.

[Spartakovic]

I wonder if it wouldn't be more straightforward instead of having no-op lock, just make a decision about locking on DiggerExecutor level.
No-op locking and type checking a level higher look more like workarounds

[duoctranth]

I wonder if it wouldn't be more straightforward instead of having no-op lock, just make a decision about locking on DiggerExecutor level. No-op locking and type checking a level higher look more like workarounds

Thank you for your suggestion. I understand your point about making the decision about locking on the DiggerExecutor level instead of using a no-op lock. While it's true that using no-op locking and type checking at a higher level can be seen as workarounds, the reason we opted for this approach is to keep the code changes minimal and provide the flexibility to customize the locking behavior in the future if needed.

By using the no-op lock, we can easily switch between enabling and disabling locking without modifying the DiggerExecutor logic. This allows us to maintain a clear separation between the locking mechanism and the executor logic. Additionally, it provides an opportunity for customization by allowing different messages to be displayed later on.

However, I appreciate your input, and if you think there is a more straightforward approach that aligns with the project's goals and architecture, I'm open to discussing it further. Let's explore all options and come up with the best solution together. Feel free to share any specific ideas or concerns you have regarding the locking implementation.