Add hourly/quarterly frequency support for the 15-min market (#15), fix Periodo parsing (#14)

[KoscheiiB]

Hi @acruzgarcia, following up on #15. This adds the quarter-hour support, in two commits so the
standalone bug can land on its own if you prefer.

The first commit fixes the Periodo rename (#14). Since 2025-10-01 OMIE renamed the period column
from Hora to Periodo in the day-ahead files. The energy-by-technology reader still mapped only
Hora, so for any current date
df[get_keys()] raised on the missing HOUR column, which is the empty/broken DataFrame in #14. The
fix maps Periodo to HOUR (accent-insensitive, so it also tolerates CARBÓN vs CARBON) and adds
the two new technology columns (ALMACENAMIENTO, HIBRIDACIÓN). It stands on its own and fixes
current hourly-named files regardless of the quarter-hour work.

The second commit adds the frequency parameter (#15): a Frequency enum (HOURLY, QUARTERLY)
threaded through the importers and readers for the two day-ahead files that come in both resolutions,
marginal price and energy-by-technology. QUARTERLY returns the full 96 periods (H1Q1..H24Q4), and
an empty frame before 2025-10-01 since no quarter-hour data exists then. HOURLY, the default so
existing callers are unchanged, returns the native 24 periods for historical dates exactly as before.
The quarter values are average power (MW) per 15-min slot, not additive energy, so hourly is the mean
of the four quarters, never the sum (that sum is the bug behind the roughly 4x inflation people hit).
Tests assert the mean.

One note on the design. You suggested adding frequency to the downloaders and downloading hourly
when still possible. While building it I checked what OMIE serves now and it's a bit different from
what we'd expect, so I went a slightly different route; happy to change it if you'd rather. The
day-ahead files don't have separate hourly vs quarterly URLs; the same file flips content by date
(INT_PBC_EV_H_1_.. and INT_PBC_TECNOLOGIAS_H_.. return 24 periods before 2025-10-01 and 96 after,
at the same URL). The other published price file, marginalpdbc, went the same way: 24 rows before,
96 after (marginalpdbc_20251015.1 and marginalpdbc_20260615.1 both carry 96 periods, with values
matching the INT file). I couldn't find a current-date hourly day-ahead file under any of the usual
names.

OMIE's own file-format spec confirms it (Modelo de Ficheros, v1.37 PDF). From §3.1:

Para sesiones posteriores al inicio de la negociación cuarto-horaria, se sustituye el campo 'Hora' por 'Periodo'.

Para algunos ficheros, el campo 'Periodo' tendrá un valor alfanumérico: HxQy, siendo x el número de hora y n el periodo cuarto horario correspondiente dentro de cada hora o numérico con valores comprendidos del 1 al 100 periodo.

El documento actual describe el formato de los ficheros vigentes. Para información anterior al 30 de septiembre del 2025 será necesario comprobarlo en la versión anterior a este documento.

So for a current date there's no hourly file to download, only quarter-hour. That's why frequency
sits on the reader/importer, where it decides output shape, rather than the downloader, whose URL
doesn't depend on it. For the case where you ask for hourly but only quarter-hour exists, I left the
aggregation opt-in rather than forced: derive_hourly_from_quarters defaults to False (returns
nothing, faithful to what was published) and True gives hourly as the mean of the quarters. That
keeps the historical hourly contract intact and makes the quarter-to-hourly math a choice. If you'd
prefer the parameter on the downloaders, or a different default, I'll adjust.

Two related things are out of scope here, because they are new upstream surface rather than fixes to
existing readers. OMIEData has no commercial-capacities reader today, so that one is a new file type,
not a change to current behaviour. The day-ahead aggregated supply/demand curve is similar: under
§5.1.3.1 of the v1.37 spec it is now a quarter-hour curve (periods as HnQn), published per day as
curva_pbc_YYYYMMDD on the file-download endpoint, which is a different file and format from the
per-hour INT_CURVA_ACUM_UO_MIB_1_HH_.. that the current SupplyDemandCurveDownloader builds. So it
is an addition rather than a fix. Each would be its own separate PR, and worth pursuing only if it
fits the direction you want for OMIEData. If you'd want either of them upstream, let me know which way
you'd like to take it and I'm glad to put it together.

Tests are in tests/filereaders_tests/quarterly_support_test.py (9 of them): quarterly returns 96,
quarterly before cutover returns empty, hourly native unchanged, hourly-on-quarter default-empty vs
opt-in mean, and the Periodo fix. Fixtures are real OMIE files from before and after the cutover. The
existing reader tests still pass (two pre-existing failures on pandas 3.x are unrelated).