I for one would much rather have too much information than not enough information.
This is very detailed in the requirements and definitely going to be achievable. However, it’s not going to be easy so I recommend starting small and gradually building it up. Come up with your minimal end to end thread and implement that. Then build on that adding in more and more.
A system like this is often best implemented using a state machine. 0-8 are your top level states. So your overall rules logic is going to mainly be involved with transitioning between those modes for the other modes. Under what conditions/states/events are a state transition required? Approach it from that and then the rest becomes just sending the right commands to the right devices.
Start small. Get the relays and sensors into OH. Experiment with how to command them and how the states are updated manually. Follow the Getting Started Tutorial for how to get an end-to-end thread going. As you learn it will become apparent how to proceed.
The Astro binding has a Channel that tells you the seasons. What to do during that season can be encoded using Items or Item metadata.
But this should be one of the last things you look at implementing. Get the basics working first.
I recommend Time Based State Machine [4.0.0.0;4.9.9.9] and/or Timeline picker to setup heating, light and so on.
It’s going to be driven by the details. See Rules | openHAB and Rules - Introduction | openHAB (which includes more than 1-2 examples) for generic details.
I see no reason why these cannot be implemented with basic and Blockly Rules. You don’t need to get into heavy coding I think.
I would probably start with creating Scenes (Settings → Scenes) with the states of all the Items for each mode. Then work on Rules that implement the state transitions through the rule triggers and conditions. That will work to get you started but eventually you’ll probably need to be more dynamic and you’ll move the Scenes into a Script Action in the Rules where you can calculate the commands to the Items instead of hard coding them in the Scenes.
It’s just an Item that’s ON when someone is present and OFF when not. How do you detect someone is present? 
It can be a challenging problem without a universal solution that works for everyone. It depends on how many people are involved, whether they always have their phone on them when they leave, and details like that. Sometimes it can be as simple as the phone reporting when the home SSID (that’s what I do) is near, slightly more complicated like geotracking, to as complicated as the Wasp-in-the-Box algorithm or Bayesian probability trees.
But ultimately it’s a separate set of sensors and rules that toggle a switch.
It’s just a Switch Item.
Have you reviewed the Concepts page of the docs and Getting Started Tutorial? A lot of these questions should be answered there. If not it would be helpful to understand what isn’t clear so we can improve them.
It’s easy enough using a String Item.
Some people use Number Items but I think using a String Item is more intuitive and self documenting. The Time Based State Machine uses this approach.
Pages - Introduction | openHAB through the start of the Rules section.
Getting Started - Introduction | openHAB through the start of the Pages section.
And don’t skip the Concepts sections of the main docs which explains bindings, Things, Channels, Items, and Rules.