Refactor: Generalize add component functions

[lkstrp]

What is the reason for having both n.add and n.madd? Right now, there are two versions with duplicate structures that also don't have the exact same behavior, which leads to bugs (see #867). This is hard to maintain, not a clean API and I don't see the reason for that or am I missing something?

We could generalize both and deprecate n.madd, that would be the cleanest solution and a consistent API. But a big interference in the API, but currently I don't think it breaks anything. I'll add a Draft PR below, which already has a uniform n.add function. All tests run through, but this is a draft.

If both should be kept for some reason, at least the redundancy can be resolved so that both functions only serve as wrappers.

What do you think @fneum @FabianHofmann ? Take a look at the PR

[fneum]

I am happy for n.madd to be deprecated and integrated into n.add. This is a good idea and could also be applied to n.mremove and n.remove, respectively. The following aspects should be double-checked:

• ensured backward compatibility of n.madd joint with deprecation note (using deprecation package)
• checks for potential performance degression of "new" n.add compared to n.madd for adding many components at once

Generally, I would say we have mostly used n.madd and less n.add.

[FabianHofmann]

Yes, deprecating madd and generalizing add sound like a good idea (same with remove)!

[coroa]

And for history's sake: We started with scalar net.add and found that we had to work around that for efficiency, then had the madd variants as external helpers and finally decided to integrate them directly since we found we were using them pretty exclusively.