It was introduced a (very) long time ago (c7bf03e), was barely changed since then and seems unused by now.
Apparently it was used mainly to get installation's Python to PATH (`set PATH=%PYTHONHOME%;%PATH%`). It was also setting and env variables based on the cache as a side effect.
If needed, we'll be able reintroduce it later, delegating most of the logic to Python.
`TARGET_ARCH` has exactly the same values as `VS_PLATFORM` - "x64", "ARM", "ARM64") except it has `x86` instead of `Win32`, but this value is never actually used, so both variables end up using interchangeably, making code harder to reason about - you needed to remember that they're exactly the same except the case when the variable is passed directly to VS (either through `cmake -A` or some `msbuild` command), then user must use `VS_PLATFORM`. So we might just use one variable always.
`START` is set to `0` for "amd64" / "x64" and `1` in all other cases, effectively just skipping `GENERATORS[0]` in case when "amd64" or "x64" is present.
Which is now useless, since `GENERATORS[0]` doesn't exist anymore.
They were added awhile ago in 67666ed for overcoming some win32 issues, which is not around anymore.
And now `VS_HOST` is never set (and therefore `VS_TOOLSET_HOST` is always empty too) and likely to be never used.
CI was failing:
```
The system library `dbus-1` required by crate `libdbus-sys` was not found.
The file `dbus-1.pc` needs to be installed and the PKG_CONFIG_PATH environment variable must contain its parent directory.
The PKG_CONFIG_PATH environment variable is not set.
```
There was an error building a standalone ifcwrap when previously built IfcOpenShell had rocksdb - `_ifcopenshell_wrapper.cpython-314-x86_64-linux-gnu.so: undefined symbol: _ZTV17RocksDbSerializer`.
`IFOPSH_WITH_ROCKSDB` propagated to the build, requiring rocksdb symbols, but `WITH_ROCKSDB` wasn't set and `document_serializer_rdb` target wasn't provided.
Otherwise it will never be able to reach standalone ifcwrap build as in this case ifcopenshell is built first as a dependency without `BUILD_IFCPYTHON`.
When fixing warnings, noticed that was working a bit inproperly - `bnode` always end up being an empty list (because there's no `brick, A, REF.IFCReference` triple), so then passing empty list to `triples` resulted in selecting all nodes isntead of just the expected `bnode` (that's the behaviour `sqlachemy` was sending the warnings about - when empty lists unexpectedly selected everything).
`None, None` assumed by default.
Though this was introduced in Python 3.13, before 3.13 it only breaks if we'd do `typing.Generator[T]` (which is deprecated) -`collections.abc.Generator[T]` works fine, it seems it never had an arity check.
Raising `AttributeError` is definitely wasn't correct here, since it
might push the code to assume it's a wrong entity type. Returning some stub value like `None` also could suggest incorrect derived attribute
value, leading to unexpected behaviour. So adding an error, so it would
propagate and code would need to be adjusted not to rely on derived
attributes, if it actually interacts with sql/stream.
`test_unit` was asserting that derived attr will return `None`, though
it was actually raising `AttributeError`.
Andrej730