Remove thiserror in favor of derive_more

[KillingSpark]

This switches to derive_more so we get

1. Nice formatting of the errors (both for no_std and std)
2. Get to be no_std on stable instead of only nightly
3. Still have the Error implementation if the std feature is enabled

Fixes: #47

[tamird]

LGTM. Is this ready to land?

[tamird]

You might want to change CI to test against stable rather than nightly:

zstd-rs/.github/workflows/ci.yml

Lines 78 to 140 in e15eb1e

	- name: Install nightly toolchain
	uses: actions-rs/toolchain@v1
	with:
	profile: minimal
	toolchain: nightly
	override: true
	- name: Run cargo check without std feature
	uses: actions-rs/cargo@v1
	with:
	command: check
	toolchain: nightly
	args: --no-default-features
	test-no-std:
	name: Test Suite (no_std)
	runs-on: ubuntu-latest
	steps:
	- name: Checkout sources
	uses: actions/checkout@v2
	- name: Install nightly toolchain
	uses: actions-rs/toolchain@v1
	with:
	profile: minimal
	toolchain: nightly
	override: true
	- name: Run cargo test without std feature
	uses: actions-rs/cargo@v1
	with:
	command: test
	toolchain: nightly
	args: --no-default-features
	lints-no-std:
	name: Lints (no std)
	runs-on: ubuntu-latest
	steps:
	- name: Checkout sources
	uses: actions/checkout@v2
	- name: Install nightly toolchain
	uses: actions-rs/toolchain@v1
	with:
	profile: minimal
	toolchain: nightly
	override: true
	components: rustfmt, clippy
	- name: Run cargo fmt
	uses: actions-rs/cargo@v1
	with:
	command: fmt
	toolchain: nightly
	args: --all -- --check
	- name: Run cargo clippy
	uses: actions-rs/cargo@v1
	with:
	command: clippy
	toolchain: nightly
	args: --no-default-features -- -D warnings

[tamird]

Dang, derive_more also depends on syn@1. Severing that dependency edge was my motivation for #48.

They bumped the dependency in JelteF/derive_more@1fb07f1 but it is not yet released.

[KillingSpark]

Dang, derive_more also depends on syn@1

Yep but they are having beta releases for a 1.0 which makes ma hopeful that this will soon be rectified

I'm pretty busy right now, I'll try and merge this next week

[KillingSpark]

Okay so I think the way I'm going to handle this is merging this, and bumping derive_more to 1.0 once they release it.

This will allow all three goals above to be reached now and gives a clear-ish roadmap (wait for derive_more 1.0 release) towards not compiling syn 1.0 AND syn 2.0 in the future.

[tamird]

Cool, thanks. Will you cut a new release with this change?

[KillingSpark]

Today @tamird ;)