Some suggestions of engineering formats/languages

I'm a noob programmer, but I also a noob hardware developer 🤯

Although there is also a lot of open source hardware in GitHub, many hardware engineers have no idea with linguist. This is probably why I keep getting unsupported hardware formats when editing `.gitattributes`. **So now I list up some common engineering formats, hoping to get support.**

It is worth mentioning that some common formats in hardware design already exist in `languages.yml`. Such as `KiCAD` `Altium Designer` `Eagle` `Gerber Image` `Wavefront Object` `STL`... Yes, none of them are programming languages, they are considered as `data` by default, and the identification of these file types must be manually increased in `.gitattributes`. But it still makes sense to expose these formats as languages, because it really helps hardware designers quickly find the items they need.

It's really important to differentiate these formats from design softwares with language statistics. Because like when a Python developers is looking for sorting algorithms, they wouldn't expect to find a repo written in Java. That's why I wrote an [all-in-one `.gitattributes`](https://gist.github.com/TitanRGB/61c37bf71159cc9a511558ec7c218339) and use it in all my hardware projects.

Those formats below are what I wish to add support for. They are similar to the existing ones, also files of circuit design software or files of 3D/2D design softwares:

### 1 LCEDA (a.k.a EasyEDA) [-->【Wikipedia】<--](https://en.wikipedia.org/wiki/EasyEDA)

A free circuit design software. Similar to KiCAD, Eagle and Altium Designer.

| Extension | | Search | Results |
| ---------------- | ---------------------------------------------- | ------------------------------------------------------------ | ------- |
| .json (PCB file) | keyword: `editorVersion` `canvas` `shape` | https://github.com/search?q=extension%3Ajson+editorVersion+canvas+shape&type=Code | 1301 |
| .json (SCH file) | keyword: `editorVersion` `canvas` `schematics` | https://github.com/search?q=extension%3Ajson+editorVersion+canvas+schematics&type=Code | 279 |
| .eprj | original format, the only | https://github.com/search?q=extension%3Aeprj&type=Code | 135 |
| .epcb | original format, the only | https://github.com/search?q=extension%3Aepcb&type=Code | 3 |
| .esch | original format, the only | https://github.com/search?q=extension%3Aesch&type=Code | 7 |
| .elib | not unique | / | / |

### 2 Autodesk Fushion 360 [-->【Wikipedia】<--](https://en.wikipedia.org/wiki/Fusion_360)

An industrial modeling design software that is very popular among hardware enthusiasts. It has a compositional relationship with Eagle.

| Extension | | Search | Results |
| --------- | ------------------------- | ----------------------------------------------------- | ------- |
| .f3d | original format, the only | https://github.com/search?q=extension%3Af3d&type=Code | 16656 |

### 3 Computer Aided Design (CAD) [-->【Wikipedia】<--](https://en.wikipedia.org/wiki/Computer-aided_design)

Common format standard. The CAD file in the narrow sense refers to `.dwg` and `.dxf` format, which is the most suitable format for CAD packages. The most mainstream CAD package is [AutoCAD](https://en.wikipedia.org/wiki/AutoCAD).

| Extension | Search | Results |
| --------- | ----------------------------------------------------- | ------- |
| .dwg | https://github.com/search?q=extension%3Adwg&type=Code | 73803 |
| .dxf | https://github.com/search?q=extension%3Adxf&type=Code | 143039 |

### 4 Initial Graphics Exchange Specification (IGES) [-->【Wikipedia】<--](https://en.wikipedia.org/wiki/IGES)

Common format standard. Extensive CAD.

| Extension | Search | Results |
| --------- | ------------------------------------------------------ | ------- |
| .iges | https://github.com/search?q=extension%3Aiges&type=Code | 2769 |
| .igs | https://github.com/search?q=extension%3Aigs&type=Code | 8276 |

### 5 STEP [-->【Wikipedia】<--](https://en.wikipedia.org/wiki/ISO_10303-21)

Common format standard. Also extensive CAD, ISO_10303-21.

| Extension | Search | Results |
| --------- | ------------------------------------------------------- | ------- |
| .stp | https://github.com/search?q=extension%3Astp&type=Code | 203425 |
| .step | https://github.com/search?q=extension%3Astep&type=Code | 283678 |
| .stpnc | https://github.com/search?q=extension%3Astpnc&type=Code | 3 |
| .p21 | https://github.com/search?q=extension%3Ap21&type=Code | 324 |
| .210 | https://github.com/search?q=extension%3A210&type=Code | 4255 |

Start by reviewing languages.yml and .gitattributes, along with the proposed extensions and format examples in the issue. Check how existing hardware and design formats are represented before determining which of the requested formats can be supported. Done means the selected formats are represented consistently and their handling in .gitattributes is covered.

Written by the indexing model from the issue text.