Break up background and foreground effects

[bencodeorg]

A proposed follow-up to https://github.com/code-dot-org/dance-party/pull/672 -- there is very little shared between background and foreground effects, so we could potentially totally separate them.

Some pros and cons I considered while putting this together -- I'm leaning towards this feeling like a good idea, but could be dissuaded :):

Pros:

• Clear delineation between foreground and background effects
• Palettes are only relevant to background effects, so we can keep palette-specific code with the background effects.
• Simpler constructor for foreground effects that reflects only the arguments it actually needs.

Cons:

• There's not much of (any?) difference between foreground and background effects from p5's perspective (ie, I think they're all just "effects" and our consumption of them is what breaks them into foreground and background effects), so it kind of makes sense to have them together
• There's at least one dependent repo (p5-replay, I think used to generate animation videos) that would need to be updated to accommodate this change. Refactor looks straightforward though (and we may have already made breaking changes that we haven't incorporated there yet).

[bencodeorg]

Making a couple more changes here, will re-request review when they're done!

[bencodeorg]

Left a couple questions. Also curious if you were going to use the more modern syntax as @sanchitmalhotra126 had mentioned from #672 (review).

@fisher-alice re: modernizing syntax, I couldn't quite figure out why import statements aren't working, and it felt like work that could be picked up separately (maybe in conjunction with the "move effect definitions from object syntax to class syntax"?)

[fisher-alice]

Left a couple questions. Also curious if you were going to use the more modern syntax as @sanchitmalhotra126 had mentioned from #672 (review).

@fisher-alice re: modernizing syntax, I couldn't quite figure out why import statements aren't working, and it felt like work that could be picked up separately (maybe in conjunction with the "move effect definitions from object syntax to class syntax"?)

Sounds reasonable to me!