Respect .gitignore

[LiamPattinson]

Fixes #231

I spent a while trying to get Ruff's implementation of this working, but it required pulling in a lot of additional infrastructure that I didn't fully understand, so this seemed the safer option.

The use of the WalkBuilder seems messy, but when I tried building and using it from a function chain I got all kinds of lifetime issues. Making it mut and modifying it one line at a time seemed to do the trick.

[ZedThree]

Is it not possible to build the walker at this level? Then we can avoid building a new walker for each individual directory. It might also make it easier to switch to the parallel walker in the future

[LiamPattinson]

I tried to do it this way initially but ran into a bunch of problems getting it to work properly. I can give it another go.

[LiamPattinson]

7869a73 implements this. It makes the function a fair bit messier, as invalid paths need to be handled separately. WalkBuilder will raise an error if it's given a path that doesn't exist, but we need them to persist (either that or we rewrite the whole way we're handling missing files, but as there are already outstanding bugs related to the reporting of missing files I'd rather keep things the way they are in this PR if we can).

[LiamPattinson]

I've made the requested changes. I think we may need to rethink how to handle invalid file paths and missing files, as the current method is to deliberately allow these to propagate out of get_files and then catch them here:

fortitude/fortitude/src/check.rs

Lines 986 to 1002 in e03b00a

	let diagnostics_per_file = files
	.par_iter()
	.progress_with_style(progress_bar_style)
	.with_prefix("Checking file:")
	.filter_map(|path| {
	let filename = path.to_string_lossy();
	let source = match read_to_string(path) {
	Ok(source) => source,
	Err(error) => {
	if rules.enabled(Rule::IoError) {
	let message = format!("Error opening file: {error}");
	return Some(Diagnostics::new(vec![DiagnosticMessage::from_error(
	filename,
	Diagnostic::new(IoError { message }, TextRange::default()),
	)]));
	} else {

Perhaps it would be better to instead return Vec<Result<PathBuf, _>> from get_files and propagate the error directly. I think I'd prefer to handle that in a different issue/PR though.

[ZedThree]

Could be an opportunity to add some debug!() messages for why files are included/excluded

[LiamPattinson]

Could be an opportunity to add some debug!() messages for why files are included/excluded

There are a couple of bug reports I've been meaning to raise related to file searching, and I think a more general refactor of this part of the code will be needed, so the PRs to fix those would be a better place to add them.