Quite feasible, yes, but these commercial controllers are a lot smarter than I think you realise. You need to be more rigorous in thinking about the safety of your system, e.g. what is it going to do when the tank is at its high-temp limit and the sun is out? You need to run the circulator to stop the panel overheating, and you need to have over-temp dumping, etc. Are you going to pump in order to prevent frost pipe-bursts? Under which conditions and how much energy can you expend on it?
Have a look at PID controllers, which you can use to control pump running times/power/whatever to optimise the thermal energy flow obtained from the solar panel against the power wasted on the circulation pump. And in planning the flow rates, take into account the solar panel's effectiveness, etc.
How are you going to safely isolate the electrical inputs and outputs?
Have a look into the concept of a state machine. Figure out all the possible states your system can be in (startup, idle, circulating, overtemp, gas-heating, etc) and the logical conditions (comparisons between inputs and internal variables) that cause it to move from one state to another. Draw out the state machine - this is the part that people should probably review carefully - to make sure there are no transitions missed and that critical conditions are always evaluated, etc.
Think what happens if the software crashes. Is it still safe? Can you build some safety into the interface electronics that makes it respond better/more-safely if the software stops for some reason? Some means of using hardware to prevent outputs being set in a dangerously inconsistent way? For example I have a thermal controller for an audio amplifier, it's an arduino with a pair of DS1620 sensors, each of which works like an DS1820 but with additional high/low outputs; if my software crashes and it overheats then the DS1620's high outputs will kill the power. If my software is dead, the fan is wired so that it will come on at full power, etc. Your gas tap for sure MUST turn itself off if the software crashes, and that needs to be guaranteed by the hardware.
What are the common failure modes of your sensors? If they fail, what will your software do, and is that a hazard? For example if you melt a thermistor and it goes short-circuit and you've got it wired up so that a shorted thermistor indicates "minimum temperature", will it just turn the gas on and leave it on? And boil your tank, all the while thinking it's cold? You need to make sure that your input and output directions are configured so that a failure doesn't do something inherently risky (e.g. failed thermistor must make your software think the tank is hot not cold), and you need to make your software smart enough that it can detect physical faults, e.g. if we turn the gas on, do we see the temperature rising with the expected time/temp profile? If not, then there is a possibly-hazardous fault such as extinguished flame (gas leak! you must have flame-presence sensors in the hardware that operate with NO software intervention) or a failed temperature sensor.
As to the thermistor, an arduino does not measure resistance. There is no such thing as a "resistance input", only voltage inputs. There is no such thing as "resisting (half of) a load"; those words just don't go together like that in electronic engineering. However If you put your thermistor (Rt) in series with another resistor (R1), then the voltage at their junction will be Vcc*Rt/(R1+Rt) which, being a voltage, is something the arduino can measure. Anyway, the digital temperature sensors are far easier to interface and more accurate, as long as you can find one that covers the temperature range (INCLUDING fault conditions like accidental overheat) that you need.