Link To app.fs In Docs For Objects That Can Be Constructed From File Paths

Hi again,

This is a feature request.

For objects that can be constructed from file paths -- such as [ColorSpace](https://github.com/aseprite/api/blob/main/api/colorspace.md#colorspace-1)s, [Sprite](https://github.com/aseprite/api/blob/main/api/sprite.md#sprite-1)s and [Palette](https://github.com/aseprite/api/blob/main/api/palette.md#palette-1)s -- I think it would be helpful to mention and to link to `app.fs`, specifically [this section](https://github.com/aseprite/api/blob/main/api/app_fs.md#file-system-access). This gives readers a heads up for how they can get greater flexibility over error handling, such as when a file path is invalid. I was messing around [pcall and xpcall](https://www.lua.org/manual/5.4/manual.html#2.3) with inconsistent results before remembering `app.fs`. I'm still using `xpcall` for palettes loaded from presets (this is in Aseprite v. 1.3beta-6).

Alternatively, a more dramatic revision would be to remove constructors that accept file paths. Loading functions can then be shifted to app.fs, where it is clearer that an error may be raised, `nil` may be returned and more functionality for error handling can be provided.

Thank you for considering.
Best,
Jeremy

Read the constructor sections in api/colorspace.md, api/sprite.md, and api/palette.md, then compare them with the File System Access section in api/app_fs.md. Confirm whether the requested scope is cross-linking and explanatory notes or the alternative constructor redesign. Done means the chosen documentation change is applied consistently and the links point to the named app.fs section.

Written by the indexing model from the issue text.