Cargo.lock handling to be same across examples

[finalyards]

I'm... having second thoughts about this, but since I volunteered in #482 to make one, here goes.

We can continue discussion here - the PR is intended to fulfil the specs in that discussion.

[finalyards]

I made a second branch, last week, the diff to origin/main is there.

Disclaimer: I'm not claiming this to be the truth. I'm just trying to make the Cargo.lock policy least invasive for me, as a developer, and keep it useful for the repo. I first thought my approach is disruptive, but Copilot sees it more as a continuation of the stated Cargo guidelines. (granted, Copilot has a tendency to agree; you be the judge of it)

In short, I would:

• remove Cargo.lock's from the examples/
• retain them for tests
• ..which involved adding one for host/
• ..with the assumption (mildly googled) that it will not be used by Cargo, when using host as a dependency. It's meant for the tests

This move keeps one or two Cargo.locks so that CI caching can be based on them, and cargo test --locked would keep some consistency to the runs.

Let me know what you think. If you show 👍 for the approach, I'll make the PR represent it, instead.

ps. I asked Copilot to summarize the approach as the CONTRIBUTING.md.

[lulf]

Lgtm

[finalyards]

The CI states no space on device.

I don't think I can fix that in any way? Let me know when there's a chance it might pass.

[lulf]

I'm sorry, this PR just doesn't make sense to me anymore, and changed a lot since I approved it.

1. Remove the contributing.md - I don't think it's really needed to explain so much about the lock policy. It's just common rust pratice
2. Examples should have lock files, don't remove them

This is how I want the .gitignore to look like:

**/target
**/target_ci
host/Cargo.lock
host-macros/Cargo.lock
bt-hci-linux/Cargo.lock
examples/apps/Cargo.lock
examples/tests/Cargo.lock
.idea

[lulf]

This should still be **/target_ci I think?

[finalyards]

There's only one target_ci used, ever, whereas target can be in the subdirs. I like to be explicit with these patterns - narrow is better than general.

[finalyards]

@lulf I didn't intend to mislead, or hijack my own PR. I considered what you meant by "lgtm" and decided it was in the context of the above comment - thus went ahead and replaced the original approach with that.

This was a mistake. But since I still think that approach - no lock files needed for examples - is better, I will:

• restore this PR to where it was, and CLOSE IT.

I don't advocate the original change to the repo, any more. The branch I made in my fork remains available, if someone wants to use it as a reference. Sorry for the disturbance!!!