Drop AI and machine learning components

@brizental @boklm @clairehurst @dan @jwilde @ma1 @morgan @pierov

@donuts @felicia

As part of #43562 (closed) and #43867 (closed) I have a patch to remove the browser/components/genai/ component entirely. This basically contains the chatbot and the link preview stuff.

In addition, I'm also considering excluding the entirety of toolkit/components/ml/ (machine learning):

1. We have not audited the code, to verify mozilla's privacy claims.
2. Even if these ML boxes are local only, we do not have a realistic means of auditing their trained black box behaviour.

On the other hand:

1. I can see a world where many browser features end up being gated behind some ML, and potentially a growing number of users who may want them (recent case: translation) and want to accept the risk of "local black box from mozilla" for low-risk cases.
2. There are plenty of features where we simply trust that firefox has not implemented stuff in a way that is bad for our users. We do not verify every part of their code. The main difference is that we always could read and verify this code, if we wanted to be sure. Moreover, other people interested in firefox or its forks could do this as well.

So, which approach do we want to start with:

1. Exclude everything /ml/ from our build. Relatively simple to do, but can be vulnerable to upstream conflicts. Don't have to worry too much about upstream changes to this component. No guarantee that upstream keeps all the ML stuff in here though.
2. Rely mostly on preferences for each ML/genai feature from upstream. E.g. browser.ml.enable, browser.translations.enable and browser.ml.chat.enabled, which seem to be distinct. It can be hard to tell whether these are simply temporary preferences or whether upstream will sustain them. Moreover, upstream doesn't always stick to these preferences. So this would require auditing. In the future, it may be harder to tell which new features have an ML component: they aren't always going to put "ML" or "AI" in the bugzilla issue or preference. E.g. the PDF alt text generator, switched the preference name from pdfjs.enableML to pdfjs.enableAltText.
3. Ask upstream to implement a high-level preference/permission system for their ML stuff, so that we have a central way to disable all this stuff by default. And ask them to stick to this. Optimistic approach, haha.
4. Something else?

Personally, I think I would try approach 1, and just rely on the preferences to hide parts of the UI rather than for functionality. If it turns out we want this, we can then try a proper audit and selectively include it.

But I would like to get some kind of consensus from the team, and an idea of what our longer-term plan should be.