Add DriverIterator to iterate though the registered drivers

[Atreyagaurav]

• I agree to follow the project's code of conduct.
• I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

---

Fixes #512

I've done the simplest implementation for the first commit:

pub struct DriverIterator {
    current: usize,
}

impl DriverIterator {
    pub fn new() -> Self {
        DriverIterator { current: 0 }
    }
}

impl Iterator for DriverIterator {
    type Item = Driver;

    fn next(&mut self) -> Option<Self::Item> {
        match DriverManager::get_driver(self.current) {
            Ok(d) => {
                self.current += 1;
                Some(d)
            }
            Err(_) => None,
        }
    }
}

Which seems too simple, so I'm thinking of adding the ability to filter by metadata.

Which would be something like this:

pub struct DriverIterator {
    current: usize,
    filters: Vec<String>,
}

impl DriverIterator {
    pub fn all() -> Self {
        DriverIterator {
            current: 0,
            filters: vec![],
        }
    }

    pub fn vectors() -> Self {
        DriverIterator {
            current: 0,
            filters: vec!["DCAP_VECTOR".into()],
        }
    }

    pub fn rasters() -> Self {
        DriverIterator {
            current: 0,
            filters: vec!["DCAP_RASTER".into()],
        }
    }

    pub fn with_metadata(metadata: Vec<String>) -> Self {
        DriverIterator {
            current: 0,
            filters: metadata,
        }
    }
}

impl Iterator for DriverIterator {
    type Item = Driver;

    fn next(&mut self) -> Option<Self::Item> {
        while let Ok(d) = DriverManager::get_driver(self.current) {
            self.current += 1;
            if self
                .filters
                .iter()
                .all(|f| d.metadata_item(f, "").is_some())
            {
                return Some(d);
            }
        }
        None
    }
}

If someone needs to filter by more complex conditions, they can use the filter directly in the iterator, but providing some options for vectors and rasters seems like a reasonable thing to do.

What do you think?

[lnicola]

This feels a little overkill, I'd just keep the count test.

[Atreyagaurav]

I was thinking the same in the beginning, but repeating the same driver DriverManager::count() times would pass the test. Although that's a very unlikely mistake, this feels like a complete test.

[lnicola]

I'm personally happy enough with the current version.

[Atreyagaurav]

In that case, it's fine. Someone can always use a filter themselves.

I just thought having named methods might make it easier for the library users instead of having to navigate the metadata for specific driver capabilities.

[lnicola]

If we add those, they can use filter and return impl Iterator.

[lnicola]

r? @metasim