Upgrade to Serilog.Sinks.Http 9.0.0

[PetrHeinz]

Resolves #5

This ensures compatibility with the breaking changes in Serilog.Sinks.Http 9.0.0.

I've tried to come up with a solution compatible with both versions, but I couldn't find anything easy to use. I could use reflection, which would make this project harder to understand and maintain with a bit of performance reduction. I could use conditional compilation, but there's no way to detect the used package version, so users would still need to manually switch the version using constants.

In the end, I think just upgrading is a cleaner solution. I would love to get some feedback on this.

[curusarn]

Thanks!

What about people who can't switch to serilog 9?
Is this going to work for them or do they need to pin the version of our library?

[PetrHeinz]

@curusarn People who can't switch to Serilog 9 would see incompatibility error and would be forced to stay with v1.0.0 of our BetterStack.Logs.Serilog.

This is one of the reasons why I suggest bumping version to v1.1.0, so we can release v1.0.x down the road with important patches. Seeing that last change in this repo was 9 months ago, I'm not worried much about it. WDYT?

[curusarn]

@curusarn People who can't switch to Serilog 9 would see incompatibility error and would be forced to stay with v1.0.0 of our BetterStack.Logs.Serilog.

This is one of the reasons why I suggest bumping version to v1.1.0, so we can release v1.0.x down the road with important patches. Seeing that last change in this repo was 9 months ago, I'm not worried much about it. WDYT?

I'd bump a major version then - i.e. bump to v2.0.0. Wdyt? 🙏

[curusarn]

Lgtm. But I'd do a major version bump because of breaking backwards compatibility.

[PetrHeinz]

After talking it out releasing as minor, as Serilog.Sinks.Http is almost an implementation detail of our package, and switch to higher version doesn't change the user contract of our package.