Update copyright dates for generated Cargo manifests

[nspin]

2023 -> 2024

[lsf37]

Copyright years should usually not be updated in bulk, at least not if the idea is to figure out the year of the most recent original copyright on the file. It doesn't renew automatically, only if there have been significant changes to the file.

Lots of people do this, but they are wrong ;-)

[nspin]

I'm aware of the general rules, but I thought this case might be different.

All Cargo.toml files in this repo are generated from adjacent Cargo.nix files. The Cargo.nix files have their own copyright lines. I have not changed any of those. However, their corresponding Cargo.toml files get their copyright lines from this snippet:

rust-sel4/hacking/cargo-manifest-management/manifest-scope.nix

Lines 84 to 86 in 63ce236

	copyrightLines = {
	coliasgroup = "Copyright 2023, Colias Group, LLC";
	};

For this PR, I changed the year in that snippet and then ran the typical Cargo.toml re-generation script with make update-generated-sources.

What do you think about this particular case? The Cargo.toml files are new in the sense that they're freshly generated, but old in the sense that they are identical in content to older outputs of make update-generated-sources.

An alternative would be to include the year for the copyright line at the source-level in Cargo.nix files. That would feel a bit clunky, but would yield more control if such control were necessary.

[lsf37]

What do you think about this particular case? The Cargo.toml files are new in the sense that they're freshly generated, but old in the sense that they are identical in content to older outputs of make update-generated-sources.

An alternative would be to include the year for the copyright line at the source-level in Cargo.nix files. That would feel a bit clunky, but would yield more control if such control were necessary.

The copyright of generated code would be a mix of the copyright of the input to the generator and the generator itself, but the year/time it is generated does not really enter into it. So I guess the correct thing would be to take the year of the input file on this one.

It's not really that big a deal, I confess I just saw the large number of files with the bulk update and reacted to that. If it is too much of a hassle, I'd actually just leave it. Generally you don't really gain anything from updating the copyright year anyway. I try to keep it current on the files with significant changes, but we probably should just really not bother, because by the time copyright runs out I hope we have shifted languages and maybe computing paradigms a few times :-)

[nspin]

If it is too much of a hassle, I'd actually just leave it. Generally you don't really gain anything from updating the copyright year anyway.

What about Cargo.toml files generated from Cargo.nix files that were created in 2024?

[lsf37]

If it is too much of a hassle, I'd actually just leave it. Generally you don't really gain anything from updating the copyright year anyway.

What about Cargo.toml files generated from Cargo.nix files that were created in 2024?

Those would be fine

[nspin]

Those would be fine

By this, do you mean that it would be fine to label those with the year 2023?