rm EmbedSVG.ejs and Embed_text.ejs

[wbamberg]

Resubmitting #1040:

---

These macros were used in 1 en-US and 50-odd pages across all locales. Most of the time they made you a helpful table like this:

In these cases I just deleted the table. In a few cases the SVG code was actually there, so I just copied it into a static code block.

Now these macros are no longer called by any Wiki pages:
https://developer.mozilla.org/en-US/search?kumascript_macros=Embed_text&locale=*&page=1&topic=none
https://developer.mozilla.org/en-US/search?locale=*&kumascript_macros=EmbedSVG&topic=none

...and they're not called internally by any other macros:
https://github.com/mdn/kumascript/search?utf8=%E2%9C%93&q=Embed_text&type=
https://github.com/mdn/kumascript/search?utf8=%E2%9C%93&q=EmbedSVG&type=

[jwhitlock]

Confirmed, not used on any indexed pages. Thanks @wbamberg!

These are the last pages to use the env.files interface. This data was passed as a HTTP header at render time, and resulted in very large headers on pages with lots of files, whether they use the data or not. After a node.js security update, this broke rendering on pages with many attachments (see bug 1520574).

If you need functionality like this in the future, we can add file data to the $json API, or find other ways to get this data.

[ExE-Boss]

Fun fact: this would have broken anyway due to a logic error in MDN.getFileContent(…):

kumascript/src/api/mdn.js

Lines 127 to 135 in 4807e01

	async getFileContent(fileObjOrUrl) {
	var url = fileObjOrUrl.url || fileObjOrUrl;
	if (!url) return '';
	let base_url = '';
	// New file urls include attachment host, so we don't need to
	// prepend it
	var fUrl = url.parse(url);

See also: #1107 (review)