Eliminate thread-local storage and refactor client entry points

[jakepetroules]

We need to eliminate thread-local storage in AXRCore to ease implementation of multithreading and flexible use of the library.

We should merge the functionality of AXRCore and AXRWrapper, and potentially merge the functionality of both into AXRController; AXRController being the go-to class to render an individual document - one application, one or more AXRControllers.

Or... create an AXRDocument class which uses AXRController internally. Whatever approach makes the most sense.

[jakepetroules]

HSSRequest::fire creates a new AXRController... because AXRController takes a pointer to AXRCore, perhaps AXRCore should not be merged into AXRController but instead renamed to AXRDocument which will manage multiple AXRControllers - one AXRController per actual file.

For example...

• AXRDocument (main file: index.xml)
  • AXRController (file: index.xml)
  • AXRController (file: stylesheet1.hss)
  • AXRController (file: stylesheet2.hss)

[jakepetroules]

There are now only 3 classes that call AXRCore::getInstance that shouldn't: HSSFlag, HSSFunction, HSSRootSelector. HSSParserNode has been given methods to get and set a controller, the necessary code to call setController on every HSSParserNode-derived object needs to be written - @veosotano!

After that, AXRCore::getInstance() can be replaced with controller->document() in the three aforementioned classes. Then the next phase can begin.

[veosotano]

Let the next phase begin :)

[jakepetroules]

@veosotano - you also need to replace some calls to setController (in HSSObject and HSSParserNode) that are now redundant since the controller is now set in the constructors. I've removed the ones that appeared glaringly obvious in c0e7198, please review and see if there are any additional calls that can be removed.

Also, should we remove setController entirely at this point? I don't see why a controller would need to be changed after an object is created, unless it is cloned (in which case the object's clone method privately propagates the pointer to the new instance).

There are only 4 calls that need to be reviewed:

• AXRController.cpp:220
• AXRController.cpp:734
• HSSContainer.cpp:267
• HSSContainer.cpp:3078 - this one should be ok ONLY if we do end up keeping setController

[jakepetroules]

This is now completed! We should discuss whether to remove setController from everything entirely...