JSON.{dump,generate} offered by the JSON gem is not compatiable with
Rails at the moment and can cause a lot of subtle bugs when passed
certain data structures. This changed all direct usage of the JSON gem
in internal Rails code to always go through AS::JSON.{decode,encode}.

We also shouldn't be implementing `to_json` most of the time, and
these occurances are replaced with an equivilent `as_json`
implementation to avoid problems down the road.

See [1] for all the juicy details.

[1]: intridea/multi_json#138 (comment)

These methods now takes the same options as Hash#as_json, for example:

    struct = Struct.new(:foo, :bar).new
    struct.foo = "hello"
    struct.bar = "world"
    json = struct.as_json(only: [:foo]) # => {foo: "hello"}

This is extracted from PR #11728 from @sergiocampama, see also the
discussion in #11460.

Added Numeric#in_milliseconds, like 1.hour.in_milliseconds, so we can feed them to JavaScript functions like getTime().

Rails 4.1 has switched away from MultiJson, and does not currently
support any options on `ActiveSupport::JSON.decode`. Passing in
unsupported options (i.e. any non-empty options hash) will now raise
an ArgumentError.

Rationale:

1. We cannot guarantee the underlying JSON parser won't change in the
   future, hence we cannot guarantee a consistent set of options the
   method could take

2. The `json` gem, which happens to be the current JSON parser, takes
   many dangerous options that is irrelevant to the purpose of AS's
   JSON decoding API

3. To reserve the options hash for future use, e.g. overriding default
   global options like ActiveSupport.parse_json_times

This change *DOES NOT* introduce any changes in the public API. The
signature of the method is still decode(json_text, options). The
difference is this method previously accepted undocumented options
which does different things when the underlying adapter changes. It
now correctly raises an ArgumentError when it encounters options that
it does not recognize (and currently it does not support any options).

* Remove unneeded comments.
* Use key? instead of keys.include?.

For background -
https://bugs.ruby-lang.org/issues/8468
Changset - https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/41259/diff/test/ruby/test_thread.rb

This reverts commit e5f5a838, reversing
changes made to d7567f32.

Before, you were required to attach *after* adding the methods to the
class, since the attachment process needed the methods to be present.

With this change, any new method will also be attached to the configured
namespace.

TL;DR The primary driver is to remove autoload surprise.

This is related to #12106. (The root cause for that ticket is that
json/add defines Regexp#to_json among others, but here I'll reproduce
the problem without json/add.)

Before:

   >> require 'active_support/core_ext/to_json'
   => true
   >> //.as_json
   NoMethodError: undefined method `as_json' for //:Regexp
     from (irb):3
     from /Users/godfrey/.rvm/rubies/ruby-2.0.0-p195/bin/irb:16:in `<main>'
   >> //.to_json
   => "\"(?-mix:)\""
   >> //.as_json
   => "(?-mix:)"

After:

   >> require 'active_support/core_ext/to_json'
   => true
   >> //.as_json
   => "(?-mix:)"

This is because ActiveSupport::JSON is autoloaded the first time
Object#to_json is called, which causes additional core extentions
(previously defined in active_support/json/encoding.rb) to be loaded.

When someone require 'active_support/core_ext', the expectation is
that it would add certain methods to the core classes NOW. The
previous behaviour causes additional methods to be loaded the first
time you call `to_json`, which could cause nasty surprises and other
unplesant side-effects.

This change moves all core extensions in to core_ext/json. AS::JSON is
still autoloaded on first #to_json call, but since it nolonger
include the core extensions, it should address the aforementioned bug.

*Requiring core_ext/object/to_json now causes a deprecation warnning*

It turns out that ActionPack depends on the decoder to parse JSON
"fragments" (e.g. '"a string"', '1', 'null', etc), so we need to
enable quirks mode on JSON.parse. Also added coverage on the decoder
side to prevent regression.

Since we are dealing with untrusted user input, we should not be
using JSON.load. According to the docs[1]:

BEWARE: This method is meant to serialise data from trusted user
input, like from your own database server or clients under your
control, it could be dangerous to allow untrusted users to pass
JSON sources into it. The default options for the parser can be
changed via the ::load_default_options method.

[1] http://www.ruby-doc.org/stdlib-2.0/libdoc/json/rdoc/JSON.html#method-i-load

* eliminates need for temp Hash

Also added a couple of examples to DurationTest to specify:

* duration can be defined with units out of order e.g.
  1.month + 1.year + 1.second + 1.day
* equality with a Fixnum works regardless of which operand is on which
  side of the operator

see c48cbb02

Previously, an autoloaded constant `HTML::SomeClass` would not be marked
as autoloaded by AS::Dependencies. This is because the
`#loadable_constants_for_path` method uses `String#camelize` on the
inferred file path, which in turn means that, unless otherwise directed,
AS::Dependencies watches for loaded constants in the `Html` namespace.

By passing the original qualified constant name to `#load_or_require`,
this inference step is avoided, and the new constant is picked up in the
correct namespace.

This reverts commit 70d6e16f, reversing
changes made to ea4db3bc.

Seems to be a code merge done by mistake.

That is a better name, thanks @jeremy.

See the CHANGELONG message in the patch for further details.

This change is similar to #11736 & in same way switched with fixed string & the index of the hash for method name. the index was added because otherwise, ruby will raise Error.

We need to call `in_time_zone` to test that it isn't modifying the receiver
but since the variable isn't used it raises a warning so add an assertion
to make Ruby think it's being used.

When we call define_method with non-english chars like ¿por qué? it
errors out on JRuby as of 1.7.4 & would leave out the following error

invalid byte sequence in US-ASCII

To work around this issue, I have switched to define_test method call
define method with fixed string & the index of the hash. the index was
added because otherwise, ruby will raise method redefined warning.

As far as I can see there are no side-effect of this change for
other implementations. For readbility I have added a message to
asssert_equal informing for which word/phase the test has passed.

Before this Change:
JRuby:
Tests terminated suddenly with an error. no reported of Failues
or errors
MRI:
All Green.

After this Change,
JRuby:
the `ActiveSupport` TestsSuite gracefully fails with report at the end which test failed & why.
MRI:
All Green(no change)

Similar implementations of #in_time_zone exists for Date, Time and DateTime so
method is extracted into its own module. Also some logic is extracted into
private method.

Use a lambda to ensure that the generated string respects the offset of
the time value. Also add DateTime#to_s(:iso8601) and Date#to_s(:iso8601)
for completeness.

Add Time#to_s(:iso8601) for easy conversion of times to the iso8601 format for easy Javascript date parsing

Added middle_of_day method to Date and DateTime