case issue with git and glyph layers

For several years I have imported a subset of Latin glyphs from Source Sans (using the UFOs in the Instances folders) for use in other non-roman fonts. This year the import failed, my import script uses fonttools and fonttools threw an exception
```
File "/home/bobby/.local/lib/python3.10/site-packages/fontTools/ufoLib/glifLib.py", line 204, in __init__
raise GlifLibError(f"{CONTENTS_FILENAME} is missing.")
```
[This code](https://github.com/fonttools/fonttools/blob/main/Lib/fontTools/ufoLib/glifLib.py#L203-L204
) was [added](https://github.com/fonttools/fonttools/commit/8d2a3ae6d22897d0b012d219d3a0b496b9c816d1) in 2020 to fix an [issue](https://github.com/fonttools/fonttools/issues/2111), which explains why I was able to import glyphs in 2019.

On my system (Ubuntu 22.04) I see 3 folders in the `font.ufo` folders that contain 3 folders:

- glyphs
- glyphs.com.adobe.type.processedGlyphs
- glyphs.com.adobe.type.processedglyphs

Note that the last two folder names differ only by case. The last two folders each has a `.plist` file, and many `.glif` files. No filename is in both folders. Indeed, one of the folders did not have at `contents.plist` (which is what CONTENTS_FILENAME refers to).

The string `glyphs.com.adobe.type.processedglyphs` (all lowercase) is in the UFO metadata, `glyphs.com.adobe.type.processedGlyphs` (one uppercase G) is in `.gitignore`. By moving all the files from `glyphs.com.adobe.type.processedGlyphs` to `glyphs.com.adobe.type.processedglyphs` and removing the now empty folder, the import ran without any issue. My work in 2019 was not affected by this issue, since I was taking the glyphs from the default layer.

I suspect that at some point files were added to git with the different case in the folder name. On Windows and I think macOS, those systems are generally case preserving but case insensitive, so only two folders (`glyphs` and `glyphs.com.adobe.type.processedglyphs`) would have been created by git, and this whole issue would not occur. But Ubuntu Linux generally has case sensitive filesystems, so the issue occurs.