Add init accessor to DependencyEndpoint macro

[AgapovOne]

I'm attempting to fix behavior that broke after #355.

cc @mbrandonw

I've added initAccessor boolean property, added snapshot tests for possible scenarios.

---

Still in draft because it would have a possible bug that were removed from documentation in release 1.9.2:

Old bug reproduced

I tried to add tests on issuereporting call that would be expected in this scenario.

I'm open to ideas on how we can fix this.

If we can't, probably asking everyone to provide own init is better than have this bug still here.

The library works fine with all old cases, and I just found one specific case that would break it, but it can be avoided with custom init.

[mbrandonw]

Hi @AgapovOne, I am starting to feel that even allowing the initAccessor option is maybe too much of a footgun. I just don't think people should be using @DependencyEndpoint directly. It really doesn't do that much for you. Instead of this:

@DependencyEndpoint
public var set: (ValueType?) -> Void

…you do this:

public var set: (ValueType?) -> Void = unimplemented("Unimplemented: \(Self.self).set")

So, while our change was technically a breaking change, there is a clear migration path forward, and I think we want to overall discourage people from using @DependencyEndpoint. We should probably deprecate it and replace it with @_DependencyEndpoint.

What do you think?

[AgapovOne]

I think we shouldn't bring my change into repository because it brings again this issue with missing reportIssue call.

But I want to explain where I'm using @DependencyEndpoint now.

@DependencyEndpoint
public var set(_ value: ValuType?) -> Void

Brings me named arguments. That's the only thing I'm using it for.

set(value: nil)

It's probably better to write it myself now. Or look for other macro.

---

deprecate it and replace it with @_DependencyEndpoint.

The point of this would be to discourage it's use without @DependencyClient?