Populate every element type; move the nomenclature filter into its view

Closes the gap left open by the previous commit, at the root rather than
around it.

populateElementTable()/populateElementInfoTable() only inserted elements
matching Simple|Terminal|Master|Thumbnail. That quietly made the element
table mean "the elements a nomenclature cares about" rather than "the
elements of the project": slave elements (relay contacts) and report
elements -- ordinary conductor endpoints -- had no row at all after a
project load, so the wiring list could not name either end of a wire
that terminated on one.

Both tables are now populated with every ElementData::Type, and the type
restriction moves into element_nomenclature_view, which is where a
"what belongs in a bill of materials" decision belongs. The mask in the
view is character-for-character the one the population used to apply, so
a relay contact is still not a BOM line item.

This is safe to do in one place because every consumer of the project
database goes through a view: element_nomenclature_view (the on-diagram
nomenclature table via ElementQueryWidget, the BOM dialog, and the
--export-bom CLI) or project_summary_view (which does not reference
element at all). Nothing queries the element or element_info tables
directly -- checked across the whole tree.

Regression evidence. --export-bom runs updateDB() and then queries
element_nomenclature_view, so it is an exact harness for what the GUI
BOM shows. Captured for 19 projects (all 17 usable examples/ plus two
slave-element fixtures) before and after:

  - BOM content byte-identical on all 19, compared as a multiset.
  - 18 of 19 are also identical line-for-line in order.
  - photovoltaique differs only in the position of three byte-identical
    rows among themselves. Its query is ORDER BY label and those rows
    share an empty label, so their relative order was never defined;
    they are indistinguishable in the output. The on-diagram
    nomenclature orders by every displayed column, so a tie there means
    the rows are identical on screen too.

Effect on the wiring list, same project and same reload path: element_info
rows 0 -> 2, and the two component columns go from blank to K2 -> K1.

Cost: the database phase of loading examples/industrial.qet (150 folios,
1794 terminals) moves from 0.210 s to 0.233 s.

sources/dataBase/projectdatabase.cpp

@@ -620,7 +620,13 @@ void projectDataBase::createElementNomenclatureView()
 						 "di.folio AS folio,"
 						 "e.pos AS position "
 						 " FROM element_info ei, diagram_info di, element e, diagram d"
-						 " WHERE ei.element_uuid = e.uuid AND e.diagram_uuid = d.uuid AND di.diagram_uuid = d.uuid AND (ei.exclude_from_bom IS NOT 'true')");
+						 " WHERE ei.element_uuid = e.uuid AND e.diagram_uuid = d.uuid AND di.diagram_uuid = d.uuid AND (ei.exclude_from_bom IS NOT 'true')"
+							//The element table holds every element of the project; which
+							//kinds belong in a nomenclature is this view's business, not
+							//the table's. Kept identical to the mask populateElementTable()
+							//used to apply, so what this view returns does not change --
+							//a slave element (a relay contact) is still not a line item.
+						 " AND e.type IN ('simple', 'terminal', 'master', 'thumbnail')");
 
 	QSqlQuery query(m_data_base);
 	if (!query.exec(create_view)) {
@@ -732,6 +738,30 @@ void projectDataBase::populateDiagramTable()
 	}
 }
 
+/**
+	@brief allElementTypes
+	Every ElementData::Type, i.e. no filtering at all.
+
+	The element table used to be populated with only
+	Simple|Terminal|Master|Thumbnail, which quietly made it "the elements a
+	nomenclature cares about" rather than "the elements of the project".
+	Anything else reading the table -- the wiring list, and terminal plans
+	later -- then could not see slave elements (relay contacts) or report
+	elements, which are ordinary conductor endpoints. The filter now lives in
+	element_nomenclature_view, where it belongs; see createElementNomenclatureView().
+*/
+static ElementData::Types allElementTypes()
+{
+	return ElementData::Simple
+		   | ElementData::NextReport
+		   | ElementData::PreviousReport
+		   | ElementData::Master
+		   | ElementData::Slave
+		   | ElementData::Terminal
+		   | ElementData::Thumbnail
+		   | ElementData::ConductorDefinition;
+}
+
 /**
 	@brief projectDataBase::populateElementTable
 	Populate the element table
@@ -744,7 +774,7 @@ void projectDataBase::populateElementTable()
 	for (auto diagram : m_project->diagrams())
 	{
 		const ElementProvider ep(diagram);
-		const auto elmt_vector = ep.find(ElementData::Simple | ElementData::Terminal | ElementData::Master | ElementData::Thumbnail);
+		const auto elmt_vector = ep.find(allElementTypes());
 			//Insert all values into the database
 		for (const auto &elmt : elmt_vector)
 		{
@@ -773,7 +803,7 @@ void projectDataBase::populateElementInfoTable()
 	for (const auto &diagram : m_project->diagrams())
 	{
 		const ElementProvider ep(diagram);
-		const auto elmt_vector = ep.find(ElementData::Simple | ElementData::Terminal | ElementData::Master | ElementData::Thumbnail);
+		const auto elmt_vector = ep.find(allElementTypes());
 
 			//Insert all values into the database
 		for (const auto &elmt : elmt_vector)