Fix build on Plan 9

[fhs]

Plan 9 doesn't have syscall.EAGAIN. Copy some code from Go's internal
locakedfile package to check whether the file is locked by another
process.

[welcome]

Thank you for submitting this PR!
A maintainer will be here shortly to review it.
We are super grateful, but we are also overloaded! Help us by making sure that:

• The context for this PR is clear, with relevant discussion, decisions
  and stakeholders linked/mentioned.

• Your contribution itself is clear (code comments, self-review for the
  rest) and in its best form. Follow the code contribution
  guidelines
  if they apply.

Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment.
Next steps:

• A maintainer will triage and assign priority to this PR, commenting on
  any missing things and potentially assigning a reviewer for high
  priority items.

• The PR gets reviews, discussed and approvals as needed.

• The PR is merged by maintainers when it has been approved and comments addressed.

We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution.
We are very grateful for your contribution!

[willscott]

Agree that the structure you've added here seems like a reasonable way to extend the lock function to plan9, and this follows the definitions in the standard library, so seems fine.

The one semantic thing I'm not clear on that is worth checking if you haven't yet, is that these errors will cover both the "someone else has the lock" error that they will trigger the overall Lock method returning, and the lock is already held by us case in the main lock switch statement.

I haven't looked to see if any of the callers of Lock do different things based on those errors, and my quick read at how plan9 is structuring its errors doesn't leave me overly optimistic that we'd be able to efficiently learn if the existing exclusive fid is in the same process, but it's probably worth checking to make sure there isn't code that's using those semantics.

[fhs]

If the lock is held by us, we get this error:

file "/tmp/filelock/my-test.lock" already locked

If the lock is held by another process, we get this error:

cannot acquire lock: Lock Create of /tmp/filelock/my-test.lock failed: open /tmp/filelock/my-test.lock: '/tmp/filelock/my-test.lock' file is locked

I think I already distinguish between these two errors by checking if the error string contains "Lock Create of" (similar to isLockCreatePermFail function). We depends on go4.org/lock returning two kinds of errors, but I think it's good enough solution.